You should be ok - as long as you don't exceed your power supply's max current.
Last edited:
Isolation on the Cape?
Russ, it would appear to me that for best performance (and because you are bothering to re-clock) that it could be good idea to add isolators (GMRs) on the input side of the cape? This way the onboard clocks will not have their power supply influenced by processing noise, and the outgoing I2S should be as low jitter as the oscillators and their power supplies allow. I prefer synchronous clocking on the ESS 9018 (B-IIIse), but of course for this approach to work really well one needs to have the lowest jitter on the incoming I2S feed as possible.
Russ, it would appear to me that for best performance (and because you are bothering to re-clock) that it could be good idea to add isolators (GMRs) on the input side of the cape? This way the onboard clocks will not have their power supply influenced by processing noise, and the outgoing I2S should be as low jitter as the oscillators and their power supplies allow. I prefer synchronous clocking on the ESS 9018 (B-IIIse), but of course for this approach to work really well one needs to have the lowest jitter on the incoming I2S feed as possible.
Hi all,
I just read all the posts. It's very interesting.
Now I have Airport express (Li-Ion battery powered) with optical glass cable and audiolab Mdac on my system.
I use also the cd player with coax cable to the dac.
Then I use airport with ipad to listen music from sony unlimited (320kbps aac) or found some days ago, wimp (flac streaming) and it's little better.
Did you try BBB with battery supply instead of common switching power supply? how is sound quality?
Does BBB work fine with airplay and dac connected with usb?
Changing AP with BBB I'd have a digital music player also, but I don't know how the sound quality will be.
Have you any experience on it?
I know you are working hard for i2s, but i'm not still ready to change the dac.
Has BBB got a spdif out? Or it needs i2s-->spdif converter?
Thank you all for the hard work.
I think I'll buy BBB for testing.
I just read all the posts. It's very interesting.
Now I have Airport express (Li-Ion battery powered) with optical glass cable and audiolab Mdac on my system.
I use also the cd player with coax cable to the dac.
Then I use airport with ipad to listen music from sony unlimited (320kbps aac) or found some days ago, wimp (flac streaming) and it's little better.
Did you try BBB with battery supply instead of common switching power supply? how is sound quality?
Does BBB work fine with airplay and dac connected with usb?
Changing AP with BBB I'd have a digital music player also, but I don't know how the sound quality will be.
Have you any experience on it?
I know you are working hard for i2s, but i'm not still ready to change the dac.
Has BBB got a spdif out? Or it needs i2s-->spdif converter?
Thank you all for the hard work.
I think I'll buy BBB for testing.
Cool. I2S is not listed, or is this meant by "PCM/DSD out"? Hence the question.
Last edited:
OK, so after a few days listening and fiddling with the BBB, I am about to remove it for the time being from my system.
It sounds good, I have the wifi working, with Squeezelite doing rendering duties, it draws relatively little current and is stable (been up for days without issue).
It also introduces dropouts with the Buffalo 2 (I can see the lock LED flicker each interruption to the music) which are occasional with 44.1/48k streams, but frequent with anything higher rate. It isn't a streaming bandwidth issue as it occurred with a direct Ethernet connection to an LMS server also. I suspect Miero's suggestion of poor clock stability on the BBB is accurate.
I shall wait for the cape before reintroducing the BBB. Meanwhile the RPi, though marginally less detailed and relaxed, will do streaming duties. I have experienced absolutely no dropouts or other issues with the Pi.
Regards
Mark
It sounds good, I have the wifi working, with Squeezelite doing rendering duties, it draws relatively little current and is stable (been up for days without issue).
It also introduces dropouts with the Buffalo 2 (I can see the lock LED flicker each interruption to the music) which are occasional with 44.1/48k streams, but frequent with anything higher rate. It isn't a streaming bandwidth issue as it occurred with a direct Ethernet connection to an LMS server also. I suspect Miero's suggestion of poor clock stability on the BBB is accurate.
I shall wait for the cape before reintroducing the BBB. Meanwhile the RPi, though marginally less detailed and relaxed, will do streaming duties. I have experienced absolutely no dropouts or other issues with the Pi.
Regards
Mark
Thanks for the update Goto!
Kernel type (IMHO newer realtime kernel is preferable), kernel settings, overall Linux system settings, audio/alsa settings etc will influence the performance as well as getting a rock stable clock that should improve things big time.
My guess is that rpi kernel and system settings are much more optimized due to less "horsepower" compared to the BBB (for now). Once BBB kernel and system settings has matured the same, BBB will be far superior to rpi soundwize.
I have not a BBB yet, but plan to get one, once it is available in stock again.
Cheers
Kernel type (IMHO newer realtime kernel is preferable), kernel settings, overall Linux system settings, audio/alsa settings etc will influence the performance as well as getting a rock stable clock that should improve things big time.
My guess is that rpi kernel and system settings are much more optimized due to less "horsepower" compared to the BBB (for now). Once BBB kernel and system settings has matured the same, BBB will be far superior to rpi soundwize.
I have not a BBB yet, but plan to get one, once it is available in stock again.
Cheers
Ah. I2S is a form of PCM. Generally they are used interchangeably, even though doing so is not technically correct.
Is the ES9018 more prone to these dropouts than "lesser" DAC chips? I haven't listened at length but got no dropouts with the ES9023 listening to 96k files from BBB via I2S.
I worked on a friends BII trying to use an Amanero USB to I2s and never overcame dropout issues even on 441k. I think it needed the firmware chip changing.
DPLL settings
You would probably need the different firmware chip with the wider DPLL setting to use I2S at high sample rates with the B-II.
With the B-III/B-IIIse, the DPLL is settable using the onboard switches, The DPLL width must be set high enough to accomodate the jitter inherent in your source when using I2S: while testing with the highest sample rate you wish to play back, keep openening the DPLL wider and wider (higher setting) until you achieve no dropouts.
You would probably need the different firmware chip with the wider DPLL setting to use I2S at high sample rates with the B-II.
With the B-III/B-IIIse, the DPLL is settable using the onboard switches, The DPLL width must be set high enough to accomodate the jitter inherent in your source when using I2S: while testing with the highest sample rate you wish to play back, keep openening the DPLL wider and wider (higher setting) until you achieve no dropouts.
Miero,
Thanks again for your contribution.
Just tested the drivers (without connecting to the DAC). This is what I got:
Used aplay.
With alsa dmix disabled (pcm type hw)
None of my files can play because it expects 32 bit
With alsa dmix enabled (pcm type plug)
Works as expected: 44.1K and family are resampled to the nearest 48K multiple
48K and family are not resampled but converted to 32 bit
352 and 384K not supported.
For the 48K and family sample rates, is dmix just doing bit-stuffing?
Is it better for the driver to do the bit-stuffing and advertise that it supports all formats?
(alsa dmix has a reputation for bad quality -but lightweight)
Thanks again for your contribution.
Just tested the drivers (without connecting to the DAC). This is what I got:
Used aplay.
With alsa dmix disabled (pcm type hw)
None of my files can play because it expects 32 bit
With alsa dmix enabled (pcm type plug)
Works as expected: 44.1K and family are resampled to the nearest 48K multiple
48K and family are not resampled but converted to 32 bit
352 and 384K not supported.
For the 48K and family sample rates, is dmix just doing bit-stuffing?
Is it better for the driver to do the bit-stuffing and advertise that it supports all formats?
(alsa dmix has a reputation for bad quality -but lightweight)
Last edited:
Which all seems rather counter to improving SQ from a low jitter source. I have never had any issues with other sources into the I2S interface of the B-II. Even the RPi seems to outperform the BBB in this respect.
Not a route I plan to take. I am hopeful that Russ's cape will solve the issue, so will park the BBB until that becomes available.
Mark
What time frame are you working towards Russ? No pressure, just eager anticipation.
Agreed
I think it is entirely unrealistic to expect low jitter from a commercial computer MoBo. These boards are designed to be as cost conscious as possible, not be an audiophile quality product, and the clock derivation is probably quite poor, and the power supply running that clock will be full of processor noise.
Of course, there are those that feel the re-clocking onboard the ESS chip "solves" these problems, but this is not my experience: in my experience, even the ESS chip with the ASRC active and a 100 MHz local CCHD clock sounds much better to me when fed with a low jitter I2S source.
So far Russ has suggested that his "cape" design will re-clock the I2S signal with local low jitter oscillators. If the cape is well implemented, he should be able to produce an I2S data stream with jitter levels very near the inherent jitter of the chosen oscillators (and their power supplies). One could also use an asynchronous re-clocker like Ian's FIFO to reduce the jitter before the DAC.
Or, since this adds so much complexity, one could just return to using a really good asynchronous USB interface, which can achieve the same thing when well implemented.
I think it is entirely unrealistic to expect low jitter from a commercial computer MoBo. These boards are designed to be as cost conscious as possible, not be an audiophile quality product, and the clock derivation is probably quite poor, and the power supply running that clock will be full of processor noise.
Of course, there are those that feel the re-clocking onboard the ESS chip "solves" these problems, but this is not my experience: in my experience, even the ESS chip with the ASRC active and a 100 MHz local CCHD clock sounds much better to me when fed with a low jitter I2S source.
So far Russ has suggested that his "cape" design will re-clock the I2S signal with local low jitter oscillators. If the cape is well implemented, he should be able to produce an I2S data stream with jitter levels very near the inherent jitter of the chosen oscillators (and their power supplies). One could also use an asynchronous re-clocker like Ian's FIFO to reduce the jitter before the DAC.
Or, since this adds so much complexity, one could just return to using a really good asynchronous USB interface, which can achieve the same thing when well implemented.
What is the really good "embedded" (as that's the objective of this thread) asynchronous USB interface, option you are referring to?
Also, how does going from I2S->"USB"->IS2->DAC add less complexity, you've lost me here..
Last edited:
If you read through thread you will see why I am creating the cape - think of all the features together - it is not just the audio stream - though that is of course the priority.
Also remember everyone acknowledges that using the BBB on its own is a bit less than ideal.
You particularly should think about the opportunities for direct DSD - no DoP. There are also lots of other opportunities not even discussed yet.
What is happening right now is development effort - don't let that influence your thinking too much yet - there is much work going on in the background.
Also remember everyone acknowledges that using the BBB on its own is a bit less than ideal.
You particularly should think about the opportunities for direct DSD - no DoP. There are also lots of other opportunities not even discussed yet.
What is happening right now is development effort - don't let that influence your thinking too much yet - there is much work going on in the background.
Are you just being argumentative? I did not mention an "embedded" async USB interface. Neither did I suggest there was less complexity, just that the level of complexity is comparable.
To get low jitter with the approach noted here, one would need to do this:
NAS-Ethernet-BBB-I2S-async Re-clocker-I2S-DAC
vs:
Server-USB-async USB interface-I2S-DAC
The BBB and the async re-clocker would have to have separate power supplies. My point is that if one desires high performance audio, it is not going to be simple, and that using a good async USB interarface is no more complex than using the BBB or RasPi.
Currently I am using a proto async USB interface, but this is a TPA forum so no more mention of that here.
I think Russ is on a cool path here, and I had no intention of derailing the thread, sorry if you are finding offense.
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.