• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Building an open embedded audio applicance.

Jump to Latest
#841
Yes please, am sure you could be a good coach ! BTW I did succeed last year to install and run flawlessly mpdpup, until my pc burned and the SW was discontinued by the author, so not totally dumb. Just more skilled at SAP than Linux (;-)

I use mpad or ipad as an UI
 
#842
JLOP said:
Hi all

great news !

I am using Runeaudio with the BBB, to feed waveio board, after an unsuccessful attempt with Volumio. I use USB local disk, attached to a powered USB hub.
I encounter many problems for the power off/power off, eg the USB disk is not recognized at every connection and I spend a lot of time trying to reboot in several manner each time. So I leave the BBB connected 24x7, which I don't like, and the USB disk too, which I dislike even more. I tried to disconnect the HDD leaving the BBB on, sometimes it will reconnect without any problem and sometimes I have to restart the whole process as above. The USB output in the mpd player is disconnected in the process.

Will this be corrected with the cape power management, it does not make sense to have a so called "appliance" for which the solution is power off, disconnect the power cable, press the switch S2 close to the SD card , connect power cable while keeping the switch pressed for 8 seconds until the system reboots.

I believe this is linked to the HW and not a SW issue but have no clue.

BR
Jean-Louis
Click to expand...
Due to reports of such issues, plus frying BBBs, to boot, I've pretty much decided that I'm going to have to have a power and peripheral management Arduino, handling a standby battery backup, long-term power loss shutdown, start-up, and to top it off, no hot-plugging at all. For example, a permanently connected internal HDD for core/WORM media storage, and then only allowing the network for anything else.

Here are a couple links to get started with Windows mounting.
https://wiki.ubuntu.com/MountWindowsSharesPermanently
TipsAndTricks/WindowsShares - CentOS Wiki

One major precaution: "mount -a" reloads and mounts what is in fstab. "mount" lists what is currently mounted. Not being able to mount a new mount point is recoverable, but a syntax error in fstab often isn't. So, make sure you can reload fstab and then see the share, before rebooting.

On a different note, much much earlier in the thread, Meiro noted being a USB DAC (or just transport/mixer) for the PC as a goal. Is that still the case? If so, how is it intended to work?
 
#843
Hi! I'm following this thread with great interest. I wonder, is there any possibillity to get multichannel audio out over I2S on BBB? I was thinking of using a convolver (e.g. BruteFir) for digital crossover and then get 8ch data out to my BIII.

Best regards,
Mattias
 
#846
The music player is currently embedded on the demo image.

Actually you don't need cape if you want just to test it. But cape will provide native 44100Hz, better clocks, automatic I2S/DSD format switch and signal buffering.

I assume volumio / runeaudio will add support later. Currently driver is not yet stable and neither fully tested...
 
#849
miero said:
It depends what do you need it for... It is good enough to decode and play highres files. Do you want more?
Click to expand...
miero said:
Goals:
- full support for TPA I2S cape
- add DSD
- BBB also as USB DAC for PC
- I2C control of Buffalo
Click to expand...
Whether USB in, SPDIF in, or with an analog mixer, my device will end up effectively being able to do that, as part of my requirements before I discovered this cape being developed. I'm wondering if support for that still part of the plan for the cape/driver, as per that older post, and if so, how it would be implemented, to help figure out what I need to be planning for, to make that happen as an end result, including planning the case (I'm going for a compact on-desk box, rather than big shelf or rack box).
 
#850
miero said:
I assume volumio / runeaudio will add support later. Currently driver is not yet stable and neither fully tested...
Click to expand...
Hi miero, I've been following this thread since the beginning, as very interested in the development progress of the driver. Please keep up with your great work.

During these months at RuneAudio we focused on the deep rework of the RuneUI. We have finally came out with the results of our efforts just some days ago, releasing the 0.3-alpha (for Rpi only). We are currently collecting the feedbacks (many positive ones, I have to say 🙂) and soon we will port it on BBB too.

We'll try to test a first integration of your driver in this upcoming version. In case of success, it would let users enjoy the Botic cape in combination with our ready-to-use system, without the hassle of messing with the command line.
 
#856
miero said:
bloodfromastone:
- BBB is digital device, so no analog IN.
- But later with a different cape it could be ADC.
- USB Audio IN support can be added to any Linux device via https://developer.ridgerun.com/wiki/index.php/How_to_use_the_audio_gadget_driver but the driver is not yet flexible enough
Click to expand...
My concern with USB in is that 44.1kHz(a) != 44.1kHz(b), even if both are playing back the same thing, and ALSA on the BBB is doubtfully sufficient to handle that well. Reclocking w/ the cape's clock would still leave a need for mixing before the DAC, and the extra steps of going from a reclocker to an input device to USB would be prone to being no better than not reclocking, I would imagine. It looks like the McASP0/1 might be able to handle the input, but the datasheet quickly goes beyond my level of knowledge, as do various kernel and cape driver comments and code (but, I will end up having to relearn C for this anyway, for other parts, so that may become clearer over time 🙂).

Doing it analog would be something like this:
1. BBB -> cape -> DAC B -> summing unit input B -> shared buffer
2. PC -> DAC P -> BBB-managed volume control -> summing unit input P -> shared buffer
 
#857
I don't understand neither your "44.1kHz(a) != 44.1kHz(b)" point, nor your "doing it analog" section 🙂)

From my point of view:
1. local play on BBB -> I2S -> DAC
2. PC -> USB -> BBB -> I2S -> DAC
3. PC -> Ethernet -> BBB -> I2S -> DAC

Choosing USB or non-USB should be just a selecting "local" or "remote" source.

(in theory)
 
#858
Re: Hz: Using the same rate, they would need to be able to be configured to work from a master clock that can change on them. Using their own clocks, ALSA will glitch every now and then. Using good resampling to handle drift, the BBB might be stuck with too little CPU to spare, at times. The first issue might not actually be much of a problem, but most ASRCs seem to be made to be able to accept any input frequency, but have a set output frequency, from what I know.

2. PC -> USB -> BBB -> I2S -> DAC
Click to expand...
The only sufficient way I know of is:
PC -> USB out -> I2S or SPDIF -> ASRC (set to Botic's clock(s)) -> USB in -> BBB -> I2S -> DAC
​
That would then need a rate converter device, and the USB receiver, to use the Botic's clock, and be compatible with the Botic's changing of clocks on demand, to eliminate rate settings mismatches and drift.

Re: Analog: bypassing digital timing/input issues by not trying to have the BBB handle any digital signals from outside.
Code: 
PC --> DAC
        \
         \
        Mixer -> Buffer
         /
        /
BBB -> DAC
An extra DAC, and two more opamps in the way per channel, but it will Just Work, with either or both active. A volume control IC could handle levels and muting from the BBB side.
 
#859
Totally different story:
- the BBB has miniUSB connector
- connect the BBB to PC via that connector
- on BBB load g_audio module with correct arguments
- the PC detects USB Audio soundcard
- play sound in PC
- it travels to "BBB USB DAC"
- BBB receives data on virtual USB DAC audio gadget and sends them to audio output
- ...

Just single BBB, single DAC and no analog mixing.
 
Last edited:
You must log in or register to reply here.
Top Bottom