Keep up the good work!

best, Alex

Hi Alex, sound much better IMHO wrt trying to share the usb bandwidth with HD audio playback / cat5 / wifi / local attached flash and a slow processor.

Using i2s on the Pi (not talking anything else here) is a better balanced architecture / split than shoving everything over usb.

My experience with usb audio hasn’t been a good one. We’ve been asked many times to take our DAC and shove a USB front end on it – it’s not something we’ve considered.

All is IMHO, YMMV etc etc etc.

I’m certainly not going to throw 4star on to any religious war.

G

You say that ‘it’ll sound much much better than a USB DAC’ but what is that based on? The evidence I’ve seen so far suggests the opposite. See for example this telling graph, measuring phase noise:

http://teholabs.com/docs/_media/openhifi2:i2ssources.png

Pi + i2s dac scores much worse than USB dac or an old CD player. Only USB to i2s with 2 separate external clocks (one for 44k family and one for 48k family) does better than the old CD player.
i2s may have a shorter signal path, but in the digital domain, clock quality and resulting jitter are far more important for the sound quality than signal path length.
I believe there are ways to have an external clock set the pace (if not on raspberry then on beagleboard) but as far as I know it has not been done yet for either device. Until then, both RPi and BBB come with onboard clocks that are particularly unsuitable for 44.1khz samplerate.

I know there’s no free lunches and don’t expect this setup to rival a £10k Linn streamer, but implying we should happily accept very mediocre sound quality and not worry about it because it’s cheap is a little disappointing. It should be able to rival a simple 200$ CD player at least, else it is not really a solution to anything. Fancy DACs and optimized playing software are not going to produce hifi sound if it all relies on a crappy clock that cannot produce an even 44.1k.

I have no idea where Ralf has got that information from or if it’s valid / invalid – I certainly haven’t read every line of linux code for i2s playback, and I’d be surprised in anyone else has recently. Maybe Florian knows – he wrote the i2s implementation. It’s also a moving carpet with code changes being incorporated / changed weekly. There was a point in time when 24bit was playing back as white noise (a software bug) which has been fixed many months ago, it was caused by a change elsewhere are not related to i2s playback as such.

I don’t understand the DMA discussion. DMA moves a chunk of memory contents from one location to another. It’s bit perfect.

The Pi clocks are not brilliant – we all know that and we have certainly done everything to make the best of what exists – from our boards you will see many components, if we wanted we could have just banged down the TI PCM5122 and wired it up – job done. In fact that was what our prototype was 🙂 The components are there for a reason.

The PCM5122 is working in slave mode and we use the DAC’s built in PLL to sort out the clock.

We’re talking £25 devices here guys – they will never match a £10k Linn streamer, but for the small investment it’ll sound much much better than a USB DAC and make you smile knowing that you can spend the remainder of the £10k on content, nice wine and holidays.

I find the fact that we’re all able to interact with the developers (software and hardware) first hand, make suggestions, help set product directions and be part of all this massive movement just mind blowing.

Oh, and if I could get away with charging £300+ for the Pi-DAC+ I would, but where would the fun be in that?

Also, the Sabre ES9023 data sheet appears to show no built in PLL so assuming the PCM5122 or similar PLL enabled DAC will have same jitter is simply invalid.

Gordon

Thanks for replying. I agree, source material is half the story. Accurate reproduction the other half. Can you confirm/deny Ralf’s statements about the 24/16bit downsampling/truncating and, more importantly, the clock issue? Does the DAC take over the clock function and thus low jitter, or is total jitter in the end decided by the Pi clock, as Ralf suggests?

Rubbish in -> Rubbish out.

If it’s a bad recording it will not matter what you listed to it through. A great recording / mastering will sound better than a terrible one at any bit rate / frequency. Yes our ears are all different and with age our hearing deteriorates but our eyes are similar – If I’m going to downsample a picture I’d rather start with a very high resolution one to start with. Does anyone still use a 1.3Mpixel camera to print photos from?

wrt the Pi I’d rather off load audio to i2s than attempt to stream (cat5 or wifi) in parallel to using a crappy USB audio stick. That’s why we’ve tried to keep our Pi-DAC+ and Pi-AMP+ prices as competitive as possible.

See also http://www.whathifi.com/news/high-resolution-audio-everything-you-need-to-know

lots of comments on that forum too.

Gordon@iqaudio:disqus.com

http://www.iqaudio.com