🙂
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 🙂
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.
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 is supposed to play 32bit/128khz over SPDIF.
Formula for oscilator freq is:
32bit * 2 channel * 2(slots) = 128
128 * 192khz = 24.576 Mhz
For I2s, there is no 2 slots only one, so formula is 64 * fs, which is 32bit/384khz with 24Mhz oscilator
Regards,
Denis
Formula for oscilator freq is:
32bit * 2 channel * 2(slots) = 128
128 * 192khz = 24.576 Mhz
For I2s, there is no 2 slots only one, so formula is 64 * fs, which is 32bit/384khz with 24Mhz oscilator
Regards,
Denis
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:
Thanks, that greatly improves my understanding of the issue.
Looking at the RaspberryPi I see 2 oscillators with frequencies 25.000 and 19.20 stamped on them. So, unless these aren't the actual frequencies, how would that be working?
Looking at the RaspberryPi I see 2 oscillators with frequencies 25.000 and 19.20 stamped on them. So, unless these aren't the actual frequencies, how would that be working?
Looking at the RaspberryPi I see 2 oscillators with frequencies 25.000 and 19.20 stamped on them. So, unless these aren't the actual frequencies, how would that be working?
It might play at the closest frequency to 44100 it can generate, e.g.:
25000000 / 567 = 44091.71Hz
Is it possible to have the BBB control the TP DAC just like you have done with your code & the Arduino?
My ideal would be to recreate your software for this application & then add other functionality, like the music streaming & control.
My ideal would be to recreate your software for this application & then add other functionality, like the music streaming & control.
Sure. You just have to learn the environment and write/port the code 🙂
But an Arduino is only $10 nowadays and the programming environment is much simpler.
But an Arduino is only $10 nowadays and the programming environment is much simpler.
Sure. You just have to learn the environment and write/port the code 🙂
But an Arduino is only $10 nowadays and the programming environment is much simpler.
Yer, I'm sure the whole code thing would be a bridge too far.
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.
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.
Ah crap, pretty much all my music is CD ripped to .flac 
I knew it sounded too good to me true ...

I knew it sounded too good to me true ...

Raspberry Pi does not support it either well.
BTW, resampling 44.1kHz to 192kHz using best SoX settings should be fine for CD.
BTW, resampling 44.1kHz to 192kHz using best SoX settings should be fine for CD.
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
- 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
Ah crap, pretty much all my music is CD ripped to .flac
I knew it sounded too good to me true ...![]()
Give it some time. In the mean time, use a USB interface with dedicated clocks...
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?
Yes, the driver needs to do its part too. According to some of the posts from Russ, the driver in BBB is capable of generating the 44.1 frequency. In this case, 44.122K
But just the thought that it is an approximation would kill the experience 🙂
But just the thought that it is an approximation would kill the experience 🙂
So some hope then!
In reality how "damaging" could that 0.022khz be? How accurate is the oscillator for example? Even a small amount off the desired frequency could result in a greater % off the target 44.1Khz.
In reality how "damaging" could that 0.022khz be? How accurate is the oscillator for example? Even a small amount off the desired frequency could result in a greater % off the target 44.1Khz.
- Home
- More Vendors...
- Twisted Pear
- Building an open embedded audio applicance.