I believe he is comparing the BBB using the Botic drivers with I2S direct from the BBB, no cape. That being the case I concur with the findings, the Pi using I2S is better than the BBB assuming 44.1khz files. The BBB is resampling to 48khz which is not good in SQ terms.
Very interesting, I've got both to play with & was just contemplating what clock/clocks to install on the S03.
Did you build two S03 boards, one with one clock for the RPi (synchrone) and one with two for the BBB (A-synchrone/Miero's driver)?
The AKL-S03Digital Isolator/Re-clocker by Acko will also isolate and re-clock either/or the BBB & RPi. I'm in the process of putting one together..., so no firsthand experience yet, but others seem to have had good results.
Sorry, I had jumped to conclusions and hadn't seen the S03 mentioned at all. If a dual clock S03 is being used with Botic drivers then I am surprised there is any great difference between the BBB and Pi as I2s Source.
As a related question, my understanding is an ASRC (in my case using the miniSHARC) to reclock the I2S from the Pi will reduce jitter. How would that compare with the S03?
I have an S03 bare board which I am thinking about building.
I may be using the term wrongly in context of an ASRC. In the case I am talking about I have a miniSHARC being fed via I2S. The ASRC will always change the sample rate from 44.1k (or whatever the source is supplying) to the speed the DSP is running (48k or 96k which can be set by the software). It then processes the signal as per crossover etc. set by the software outputing via I2S to your DACs, again at 48k or 96k.
Initially the plan was to use a BBB with the cape TP is developing (or possibly a twin clock S03). However I am looking at the possibility of using a Raspberry Pi instead in the hope the ASRC in the miniSHARC will deal with the jitter resulting from the imperfect clock of the Pi.
I appologise fo an imperfect understanding of the subject matter
Thanks miero,
I am using Squeezelite which allows resampling via libsoxr. So I guess I should investigate its use with a view to outputing from the BBB at 48k, setting the miniSHARC to 48k so there would be no resampling on the SHARC.
Can the BBB with your driver output at 96K or just 48K?
If the above is successful do you see that solution being as good as using a TP cape or S03 given the MiniSHARC would then do its own resampling for any datastream other than 48 or 96k?
BTW the miniSharc ASRC is done via SW on the main DSP processor as I understand it.
There are many resampling algorithms and the sox/soxr is one of the best available: SRC Comparisons
Using raw BBB you can play at 48k/96k/192k rate. But due to the low quality on-board clock the output will have large jitter.
So without cape you need good ASRC, e.g. all ESS Sabre DACs are jitter immune (with proper settings).
Using raw BBB you can play at 48k/96k/192k rate. But due to the low quality on-board clock the output will have large jitter.
So without cape you need good ASRC, e.g. all ESS Sabre DACs are jitter immune (with proper settings).
Sorry, another question if I may!
Do you know how a dedicated ASRC chip (lets say the BB SRC4192) would compare to performing the ASRC function via SOX?
If you want to believe one of our industry experts, you will likely get better results with a simple filter implemented on the computer than with any on either a separate filter chip or in a DAC chip.
The following links reference John Swenson's comments in the impact of the on-chip digital filtering versus simpler, alternative ones... See here:
Upsampling Impressions
And here:
Here's the rundown on the DAC
Taking orders
Taking orders
Taking orders
Taking orders
And here:
Are we just kidding ourselves? - Page 7
Summary: On-chip digital filters are implemented in ways that produce great
specs, but don't sound good. Using a setup where the on-chip filter is bypassed
(available on chips such as the PCM5142, AK4399 and later AKM chips, and any NOS
chip that was designed to be used with a separate digital filter chip such as
the TDA1541, TDA1543, and PCM1704, but NOT the ESS chips).
I'm looking forward to getting one of these setups implemented so I can experiment a bit with this myself.
Greg in Mississippi
The following links reference John Swenson's comments in the impact of the on-chip digital filtering versus simpler, alternative ones... See here:
Upsampling Impressions
And here:
Here's the rundown on the DAC
Taking orders
Taking orders
Taking orders
Taking orders
And here:
Are we just kidding ourselves? - Page 7
Summary: On-chip digital filters are implemented in ways that produce great
specs, but don't sound good. Using a setup where the on-chip filter is bypassed
(available on chips such as the PCM5142, AK4399 and later AKM chips, and any NOS
chip that was designed to be used with a separate digital filter chip such as
the TDA1541, TDA1543, and PCM1704, but NOT the ESS chips).
I'm looking forward to getting one of these setups implemented so I can experiment a bit with this myself.
Greg in Mississippi
Thanks Greg, plenty of reading for me to digest here but all looks to be good info.
I do recall a while back having it suggested I try the resampling available in Squeezelite (sox) for the very reason it was better than in-chip resampling. At the time it wasn't so relevant and I shied away from experimenting as it seemed quite complex (have tried to find that original discussion). But now I need to try the options available as resampling is a must with what I will be doing so its time to do the reading and experiment some.
Chris,
There is an area of potential improvement using alternate filtering for the ESS DACs. As I understand it, even though their final digital filtering can't be bypassed, the initial OSF filtering can and that can have significant benefits IF one does that upsampling upstream and is running the DAC in sync mode.
See comments by 'Barrows' on these threads:
Buffalo IIIse, new DAC build, in chassis
http://www.diyaudio.com/forums/vendors-bazaar/259996-sonore-async-usb-i2s-interface-onboard-osf.html
Ethernet, USB, Optical or Coax to my DAC??
This is what I plan to implement with a BBB & a Buffalo-II, but it is easier with the Buff-III series as I believe the OSF off option is one of the ones included in the settings DIP switches.
Greg in Mississippi
There is an area of potential improvement using alternate filtering for the ESS DACs. As I understand it, even though their final digital filtering can't be bypassed, the initial OSF filtering can and that can have significant benefits IF one does that upsampling upstream and is running the DAC in sync mode.
See comments by 'Barrows' on these threads:
Buffalo IIIse, new DAC build, in chassis
http://www.diyaudio.com/forums/vendors-bazaar/259996-sonore-async-usb-i2s-interface-onboard-osf.html
Ethernet, USB, Optical or Coax to my DAC??
This is what I plan to implement with a BBB & a Buffalo-II, but it is easier with the Buff-III series as I believe the OSF off option is one of the ones included in the settings DIP switches.
Greg in Mississippi
Again, thanks, more reading
Having read some of your earlier links I am gaining some clarity - full understanding exceeds my somewhat limited mental capability unfortunately
In my case there is the complication that the BBB will be feeding a miniSHARC rather than a DAC directly. The miniSHARC runs at 48 or 96k (user selectable) and any input not running at those frequencies gets converted via a SW ASRC implemented in the main DSP module. So my aim is to get the I2S signal at 48/96K and avoid the ASRC in the DSP which I assume is inferior to sox.
I read from John Swenson that "The current implementation in Squeezelite does upsampling to the highest interger rate your DAC cupports. Thus if your DAC's maximum rate is 192, it will upsample to 44.1 to 176.4. If your DAC does not support 176.4, you can use the -r option (or max sample rate in the gui) to set the max rate to 96, then squeezlite will upsample to 88.2. Even upsampling to 88.2 will usually make a significant improvement. There has been talk about giving the upsampling more flexibility so you could choose 192 in this case."
So given I use Squeezelite, I need to check with Triode (author of Squeezelite) if there is any way to upsample to 48 or 96k. Limitation may be in sox I guess. I presume going across the 2 frequency "families" is more complex than between frequencies in a single family.
If I can get to 48 or 96k there is another option I may explore. The miniDSP can run in input master or slave mode and there is a 24.576 master clock output available. I am thinking I may be able to supply this as the master clock to the BBB running mieros code with appropriate setting. I assume this is a cleaner clock than the native one on the BBB but in any case it is the clock that will be used for the DSP processing so I will be using it anyway. Does that sound doable?
I will ask about that on the miniDSP forum but from my reading so far I don't think anybody has done that yet.
I have tried upsampling using Squeezelite/sox on the BBB successfully, upsampling from 44.1k to 96k is possible asynchronously.
So now I need to feed a clean 24.576 master clock to the BBB in preference to the onboard clock on the BBB. As I mentioned before I can get this directly from a pin on the miniSHARC GPIO but I am also considering a dedicated high quality clock to feed an external MCK to the BBB. Probably using a NDK NZ2520SD oscillator with a low noise 3.3v regulator. My assumption is that I can get better performance from a dedicated oscillator than from the onboard miniSHARC one.
This is the primary function of the cape being developed by Russ as I understand it except I only need to supply the single clock speed for 48/96k output.
Can somebody confirm that what I am doing sounds right please? I seems very simple to implement (too simple?).
So now I need to feed a clean 24.576 master clock to the BBB in preference to the onboard clock on the BBB. As I mentioned before I can get this directly from a pin on the miniSHARC GPIO but I am also considering a dedicated high quality clock to feed an external MCK to the BBB. Probably using a NDK NZ2520SD oscillator with a low noise 3.3v regulator. My assumption is that I can get better performance from a dedicated oscillator than from the onboard miniSHARC one.
This is the primary function of the cape being developed by Russ as I understand it except I only need to supply the single clock speed for 48/96k output.
Can somebody confirm that what I am doing sounds right please? I seems very simple to implement (too simple?).
The most important things that cape from TPA will provide:
- switchable 22.5792MHz and 24.576MHz master clocks
- galvanically isolated I2S and I2C interface
- switching between DSD and I2S mode compatible with ESS DACs
- protection from voltage on BBB pins in power-down mode (required safety condition of BBB)
- ...
So ... basically yes, you are on the right path
And check this thread: http://www.diyaudio.com/forums/twisted-pear/265874-slaving-bbb-buffalo-iii-possible.html
- switchable 22.5792MHz and 24.576MHz master clocks
- galvanically isolated I2S and I2C interface
- switching between DSD and I2S mode compatible with ESS DACs
- protection from voltage on BBB pins in power-down mode (required safety condition of BBB)
- ...
So ... basically yes, you are on the right path
And check this thread: http://www.diyaudio.com/forums/twisted-pear/265874-slaving-bbb-buffalo-iii-possible.html
The most important things that cape from TPA will provide:
- switchable 22.5792MHz and 24.576MHz master clocks
- galvanically isolated I2S and I2C interface
- switching between DSD and I2S mode compatible with ESS DACs
- protection from voltage on BBB pins in power-down mode (required safety condition of BBB)
- ...
So ... basically yes, you are on the right path
And check this thread: http://www.diyaudio.com/forums/twisted-pear/265874-slaving-bbb-buffalo-iii-possible.html
Thanks, the features of the cape have grown from the original requirement for the 2 low jitter clocks. For me the clocks were the primary requirement - others nice to have. If I can achieve what I am after with a single low jitter clock and upsampling on the BBB I am happy tho I may look into galvanic isolation later.
Of course all this is made possible by your drivers and I am very grateful for your work there.
Do you have any thoughts on the longer term direction for the Botic drivers? Different distros, integration into distros and longer term support?