• 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.

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
:)
I just got a BBB delivered yesterday and have been looking around on how to get I2S output from it, I haven't seen any new release from Volumio which might address the I2s payback for BBB yet, is it coming soon? Any hint from expert?

Its already possible to get music out of the BBB via I2S, I have had it running using the latest Debian Wheezy OS using FFMPEG. Also had music using Volumio tho I did have a problem with distortion on one channel. However there are issues with resampling to 48khz (and possibly other issues) which need addressing before its a fully working solution. As above a few people looking into it on different forums. Rune Audio also looking to get a new relase with I2S support but I don't think they will have the 48khz issues sorted. I wish I could contribute but I am hitting the limits of my knowledge!

I also have a Raspberry Pi running fine via I2S but really want to get the BBB going - better platform or our needs.

Puting my hopes on Russ to get this one sorted :)
 
BBB has 24.576MHz oscillator only. It allows to generate 48000Hz and its multiples. See the figure 45. in the BBB_SRM.pdf.

It seems that cape could add another oscillator for 44100Hz frequencies and route it to the same pin.

And switch between them via oscillator OutputEnable control pins.
 
BBB has 24.576MHz oscillator only. It allows to generate 48000Hz and its multiples. See the figure 45. in the BBB_SRM.pdf.

It seems that cape could add another oscillator for 44100Hz frequencies and route it to the same pin.

And switch between them via oscillator OutputEnable control pins.

It seems that way. Also the processor only has two integer coefficients for clock division, so there is no way to generate the 44.1K clocks from the on-board clocks.
A cape with two clocks, clean power supplies and connectors for I2S would be a good starting point... (and the drivers that would take advantage of these clocks)
 
Last edited:
It is definite that BBB cannot support 44.1KHz and family. See page 75 of the System manual: https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true

There is a 24.576 MHz connected to the Audio subsystem in order to generate the audio frequencies.

Fortunately, this is also connected to an expansion pin (GPIO3_21) and the oscillator can be disabled in s/w. For now the only way for bit perfect output is through USB.
 
I took a quick look at the RPI specs.
- I2S is generated by the Broadcom chip, a 19.2MHz clock feeds the chip
- The spec says:
"The General Purpose clocks can be output to GPIO pins. They run from the peripherals clock sources and use clock generators with noise-shaping MASH dividers. These allow the GPIO clocks to be used to drive audio devices.

The fractional divider operates by periodically dropping source clock pulses, therefore the output frequency will periodically switch between:

source-freq/DIV1 and source-freq/DIV1+1
 
Raspberry Pi does not support it either well.

I had read here MPD is not offering any audio output : Beaglebone Black - Page 3 • RuneAudio Forum that the Pi is bit perfect or are you referring to the fact that the I2S signal is out of the HDMI chip with the Pi rather than prior with the BBB (and thus likely more jitter on the Pi)?

I am running a Pi via I2S to an ES9023 - sounds fine to me but that is purely subjective.

BTW, resampling 44.1kHz to 192kHz using best SoX settings should be fine for CD.

If resampling is used as you suggested is the end result likely to be audibly different to bit perfect via USB?
 
I took a quick look at the RPI specs.
- I2S is generated by the Broadcom chip, a 19.2MHz clock feeds the chip
- The spec says:
"The General Purpose clocks can be output to GPIO pins. They run from the peripherals clock sources and use clock generators with noise-shaping MASH dividers. These allow the GPIO clocks to be used to drive audio devices.

The fractional divider operates by periodically dropping source clock pulses, therefore the output frequency will periodically switch between:

source-freq/DIV1 and source-freq/DIV1+1

If this is what is actually happening, then for 44.1K you will get and output frequency fluctuating between these two values:

19200000/435=44,138
19200000/436=44,037

For HDMI Audio, 48KHz, you get:

19200000/400=48,000 which is perfect.

Back to the BBB:

24576000/557=44,122
24576000/558=44,043

You could argue that for fixed divider, you get a better approximate frequency with BBB
 
Last edited:
If this is what is actually happening, then for 44.1K you will get and output frequency fluctuating between these two values:

19200000/435=44,138
19200000/436=44,037

For HDMI Audio, 48KHz, you get:

19200000/400=48,000 which is perfect.

Back to the BBB:

24576000/557=44,122
24576000/558=44,043

You could argue that for fixed divider, you get a better approximate frequency with BBB

But the current driver for the BBB is resampling to 48khz right? So you are saying that if the driver was rewritten to divide the oscillator frequency by 557 then we would be getting closer to 44.1khz (and bit perfect) than the Pi currently achieves?
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.