nige2000 wrote:
i need a better i2s dac i know that
dont be mad at me all i mean is i havent got rpi/bbb sq that good yet
don't worry i've not given up theres definitely something here to be got
dunno if i want to get a buffalo 3 for this project
what other good i2s dacs is there out there
Nige, I hope I didn't come across like that.
Everyone has to work towards the sound they here in their heads. The wee Pi brings me closer to that sound.
I think there are quite a few good dacs, not all DIY. DDDacs have a good reputation, the Buffalo is great, but both need attention paid to wiring and power supplies. There are others. The Hiface Dac has an I2S input. I'd suggest you'd want to put a pair of Twisted Pear Teleporters between streamer and a commercial dac, simply from a layout/packaging point of view, to keep the I2S runs short enough. Teleporters isolate the ground too, and without the added jitter of the GMRs.
About DACs - the PCM5142 that John Swenson raves about as the best sound he has heard, is not one specially manufactured for him - it is the same as the PCM5102 DAC chip used in the Ciunas but with an add-on DSP engine implemented in the silicon. What Swenson has done is to upsample the audio file to 352 or 384Khz before the DAC which means that the DAC's digital filter is turned off & he then has his own digital interpolation (reconstruction) filter which he uploads into the DSP engine of the DAC.
A somewhat similar approach is used in the PCM1794 DDDAC where he avoids using the digital filter but does not have an output filter, AFAIK. Both of these approaches are a type of NOS (non Oversampling) but using a Sigma-Delta DAC instead of the more usual multibit DAC used in NOS (TDA1543, etc)
Anyway, the point being that I doubt Nige's DAC is the limiting factor in what he is hearing.
I must get my main rig up & running again & get back to testing this.
www.Ciunas.biz
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
jkeny wrote:About DACs - the PCM5142 that John Swenson raves about as the best sound he has heard, is not one specially manufactured for him - it is the same as the PCM5102 DAC chip used in the Ciunas but with an add-on DSP engine implemented in the silicon. What Swenson has done is to upsample the audio file to 352 or 384Khz before the DAC which means that the DAC's digital filter is turned off & he then has his own digital interpolation (reconstruction) filter which he uploads into the DSP engine of the DAC.
A somewhat similar approach is used in the PCM1794 DDDAC where he avoids using the digital filter but does not have an output filter, AFAIK. Both of these approaches are a type of NOS (non Oversampling) but using a Sigma-Delta DAC instead of the more usual multibit DAC used in NOS (TDA1543, etc)
Anyway, the point being that I doubt Nige's DAC is the limiting factor in what he is hearing.
I must get my main rig up & running again & get back to testing this.
dont think the guys were ciunas bashing
more like usb vs i2s
i think it might be down to the usb of the rpi/bbb not been up to it
why so many components in the chain fixing problems with jitter and timing, are we not loosing as we gain?
should we not have one or more central mclk/s that run both a bbb and a dac device
maybe then there will be no/less problems to fix with the added benefit of a shorter signal path
sd card player, modded soekris dac, class a lifepo4 amp or gb class a/b amp, diy open baffle speakers based on project audio mundorf trio 10's
jkeny wrote:About DACs - the PCM5142 that John Swenson raves about as the best sound he has heard, is not one specially manufactured for him - it is the same as the PCM5102 DAC chip used in the Ciunas but with an add-on DSP engine implemented in the silicon.
Actually jkeny, I pointed out that Swenson is using the PCM5102 DAC chip in his forthcoming Community Squeeze Player Project and thinks it's really good.
So who used it first? You I suggest!
Maplin XM21X 12V float charging A123 26650 LiFePO4 battery/Maxwell Supercap PSU for Mitac PD10-BI J1900 Bay Trail, WTFPlay, Hiface Evo, Bow Technologies 1704 NOS DAC, StereoKnight TVC, Quad II monoblocks, ZU Audio Druid Mk4/Method Sub
nige2000 wrote:
dont think the guys were ciunas bashing
more like usb vs i2s
i think it might be down to the usb of the rpi/bbb not been up to it
why so many components in the chain fixing problems with jitter and timing, are we not loosing as we gain?
should we not have one or more central mclk/s that run both a bbb and a dac device
maybe then there will be no/less problems to fix with the added benefit of a shorter signal path
Absolutely not bashing. My experience is limited to the Buffalo really (and the Wolfson before that).
One masterclock is probably the goal though async dacs can be very good when properly implemented.
Twisted Pear Audio are looking to produce a cape for the BBB with dual low phase noise clocks and I2S brought out from the GPIO pins. I2C control of the dac from the BBB will also be catered for, enabling all manner of fancy options from volume control to display of playback rates, filter mode and so on.
I know there was no Ciunas bashing going on, Nige - I was just pointing out that your PCM5102 DAC is probably not the limiting factor in the sound.
Your point about one MCLK feeding both DAC & BBB or RPi is correct - the best, lowest jitter solution is the clock right next to the input of the DAC reclocking the I2S signals & also the same clock signal fed back to the BBB RPi or whatever is used. It doesn't matter about the jitter at the BBB, RPi as the I2S signals will be re-clocked at the DAC.
A complication enters the scene because for lowest jitter we need 2 audio clocks - one for the 44.1KHz speed family & one for the 48KHz speed family - otherwise we would have to derive all the MCLKs needed by multiply & dividing a single clock speed leading to increased jitter. This may seem like a small complication & it's not a big issue for FPGAs which can switch between clocks on their output pins without having to reboot the chip but I don't see this option in any of the ARM based devices. So some other work around has to be devised - one of which is an asynchronous I2S FIFO. Basically a system that takes incoming I2S data & independently re-clocks this I2S data on output
Jrling, I doubt I was the first to use the PCM5102 but surprisingly, I was contacted by & corresponded with the TI lead designers of this DAC chip (a Welsh guy) when he read the reviews of the JKDAC32. I also had some preliminary info & played around with PCM5142 chip when it first became available but never got the I2C communication working with it & I left it aside - hard to keep R&D & production running concurrently. Still have it all wired up - must revisit it.
Loworbit, I know that - I was just pointing out that what Nige is hearing is probably more to do with the I2S signal coming into the DAC rather than the DAC itself. Your buffalo probably uses asynchronous clocking on the ESS chip which works great to clean up bad quality I2S signals (with good quality I2S signals, however, it's best to turn off this reclocking)
The PCM5102 DAC board that Nige has doesn't do asynch reclocking - it doesn't have an onboard clock - it uses the timing of the I2S bitclock line itself so any jitter on this line will affect the sound.
Hmm, makes me wonder how the ES9023 DAC with asynch reclocking would sound connected to the RPi? Would probably be closer to what you are hearing
www.Ciunas.biz
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
If the rpi is making a mess of i2s Timing wouldn't it be quite likely that asynchronous days would preform better in that situation
The fifo is interesting and likely the quickest fix for this application
It seems to me to be a bit of a waste to put so much effort fixing what should be more correctly timed in the first place
sd card player, modded soekris dac, class a lifepo4 amp or gb class a/b amp, diy open baffle speakers based on project audio mundorf trio 10's
nige2000 wrote:If the rpi is making a mess of i2s Timing wouldn't it be quite likely that asynchronous days would preform better in that situation
Yep - it just didn't occur to me before
The fifo is interesting and likely the quickest fix for this application
It seems to me to be a bit of a waste to put so much effort fixing what should be more correctly timed in the first place
Even with the I2S FIFO, it improves with a reclocker at the DAC - you'll see that on Iancanada's DIYA thread. The FIFO is the most flexible/universal approach but still needs some help for optimal performance
www.Ciunas.biz
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
Twisted Pear Audio are looking to produce a cape for the BBB with dual low phase noise clocks and I2S brought out from the GPIO pins. I2C control of the dac from the BBB will also be catered for, enabling all manner of fancy options from volume control to display of playback rates, filter mode and so on.
LowOrbit - Now that sounds interesting. TPA will get it 'right' you can bet, without any 'Tweakers Rash' involved.
Any idea when it is expected on the market and the price?
Maplin XM21X 12V float charging A123 26650 LiFePO4 battery/Maxwell Supercap PSU for Mitac PD10-BI J1900 Bay Trail, WTFPlay, Hiface Evo, Bow Technologies 1704 NOS DAC, StereoKnight TVC, Quad II monoblocks, ZU Audio Druid Mk4/Method Sub
[quote="jrling Now that sounds interesting. TPA will get it 'right' you can bet, without any 'Tweakers Rash' involved.
Any idea when it is expected on the market and the price?[/quote]
Not for a little while, Russ only shared the layout a day or so ago. So no price yet either.
BUT - there are drivers. Miero over on DIYA has written drivers to go with Russ's idea and they are available for testing on Debian, ArchLinux and Angstrom. I need to update the kernel on my Debian installation.