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?
Good to hear!
I'm not a linux guy at all so I just wonder how this thing is to be operated - can I run a music player such as Volumio or Runeaudio on BBB and get the sound out via the cape?
Best regards,
Mattias
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...
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...
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).
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.
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
ACX:
- OK
- 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
ACX:
- OK
Hi Drew,
here is the download link.
http://downloads.sourceforge.net/project/runeaudio/Images/Raspberry%20Pi/RuneAudio_rpi_0.3-alpha_20140710_2GB.img.gz?r=&ts=1405499336&use_mirror=skylink
Bye.
Simone.
This is a testing release, so instead of updating the Dowload page we announced it in the forum in this thread, where we are collecting the feedbacks.
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
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)
)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)
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.
Re: Analog: bypassing digital timing/input issues by not trying to have the BBB handle any digital signals from outside.
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.
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 -> DACTotally 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.
- 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:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.