File-based audio playback - compressed vs. uncompressed

[AlexM]

I for one am going back to flac streaming on the SBT. I think we have proved that you can max or get close to maxing the the CPU when streaming 24/96 PCM - am thinking that the network stack must be not very good to eat more CPU than the FLAC decoder, and/or FLAC decoding is very efficient!.

Certainly if all of these mods are supposed to improve the sound by reducing CPU load, at least we know this tweak does the opposite.

[bobbasrah]

I for one am going back to flac streaming on the SBT. I think we have proved that you can max or get close to maxing the the CPU when streaming 24/96 PCM - am thinking that the network stack must be not very good to eat more CPU than the FLAC decoder, and/or FLAC decoding is very efficient!.

Certainly if all of these mods are supposed to improve the sound by reducing CPU load, at least we know this tweak does the opposite.

So in terms of CPU usage FLAC is more efficient at 24/96, and FLAC is proven 100% to contain precisely the same data.
Is audio output quality really worth examining in such an instance, if there is no stress, or data difference?

[Chops]

So in terms of CPU usage FLAC is more efficient at 24/96

Sorry Bob, you'll have to forgive me for being a little pedantic here.

When taking all factors into account, delivering FLAC files via a network connection to a SBT and playing them via digital out appears to place less demand on its CPU than PCM.

I couldn't confirm that simply decoding a FLAC file and pumping it down the digital out on the SBT is more efficient than PCM - I would think the opposite might be true. Others may know better, but I guess that plugging a USB stick into the SBT would be closer to this approach.

Chris

[bobbasrah]

Sorry Bob, you'll have to forgive me for being a little pedantic here.

When taking all factors into account, delivering FLAC files via a network connection to a SBT and playing them via digital out appears to place less demand on its CPU than PCM.

I couldn't confirm that simply decoding a FLAC file and pumping it down the digital out on the SBT is more efficient than PCM - I would think the opposite might be true. Others may know better, but I guess that plugging a USB stick into the SBT would be closer to this approach.

Chris

Please be as pedantic as you like Chris, the clearer the findings are the better, although I am totally lost on the SBT setup as I have none.

Ok, so the FLAC is putting less demand on the SBT's cpu via the network than it's WAV version. This may not necessarily mean that bypassing the network would result in the same loadings. I think Alex was looking at a usb stick test.

OK, that I can understand, but is this cycle that you have been measuring for the same delivery mechanism chucking the bitstream at the DAC for both situations. ie - the only variable left is the DAC performance for what should be the same input?

[Chops]

Ok, so the FLAC is putting less demand on the SBT's cpu via the network than it's WAV version. This may not necessarily mean that bypassing the network would result in the same loadings. I think Alex was looking at a usb stick test.

OK, that I can understand, but is this cycle that you have been measuring for the same delivery mechanism chucking the bitstream at the DAC for both situations. ie - the only variable left is the DAC performance for what should be the same input?

Hi Bob

Agreed about bypassing the n/w. I don't know what would happen but it would be interesting to find out.

Sorry, confused about the 2nd para. Could you explain? All my tests were done using the same chain: NAS->SBT->DAC. 100Mbps between NAS and SBT, Coax SPDIF between SBT and DAC. I wasn't listening so my pre-amp was not powered up but my DAC was incase any handshaking is involved that might affect load on the SBT (is SPDIF bi-directional?).

Chris

[bobbasrah]

Hi Bob

Agreed about bypassing the n/w. I don't know what would happen but it would be interesting to find out.

Sorry, confused about the 2nd para. Could you explain? All my tests were done using the same chain: NAS->SBT->DAC. 100Mbps between NAS and SBT, Coax SPDIF between SBT and DAC. I wasn't listening so my pre-amp was not powered up but my DAC was incase any handshaking is involved that might affect load on the SBT (is SPDIF bi-directional?).

Chris

Sorry about any confusion Chris....I was interested in establishing that the measurements were not cut short of delivery to the DAC which you confirmed it was not. The deilvery and conversion chain is tested complete.

The only variable left now is the external DAC conversion, but since the bitstream should be precisely the same for both cases via SPDIF given that FLAC itself is decoded 100% to what WAV would be, there should be no audible change.

[AlexM]

Hi Bob

Agreed about bypassing the n/w. I don't know what would happen but it would be interesting to find out.

Sorry, confused about the 2nd para. Could you explain? All my tests were done using the same chain: NAS->SBT->DAC. 100Mbps between NAS and SBT, Coax SPDIF between SBT and DAC. I wasn't listening so my pre-amp was not powered up but my DAC was incase any handshaking is involved that might affect load on the SBT (is SPDIF bi-directional?).

Chris

Chris,

SPDIF is not bidirectional so nothing will change as a result of the sac being on or not.

Regards,
Alex

[sq225917]

Has anyone just taken a look at the eye pattern with a scope, it's not exactly difficult. If the eye patterns on the spdif out look the same in both instances and the data stream is identical then the only thing left is noise mixed in with the spdif and rejection of that in the dac.

[AlexM]

Has anyone just taken a look at the eye pattern with a scope, it's not exactly difficult. If the eye patterns on the spdif out look the same in both instances and the data stream is identical then the only thing left is noise mixed in with the spdif and rejection of that in the dac.

I have a scope, but I don't expect to see anything different in the eye pattern based on the file type.

I found this text written by J. Gordon Rankin on the Well tempered computer site, which is relevant, and I note his comment on duff USB cables.

I have done more than 10 audio shows where we bootcamped and showed that both with FLAC/ALAC and AIFF/WAV that flat PCM files (AIFF/WAV) always sounded better.

So I setup a test as follows:

MacBook Pro (bootcamp Win764ULT) <==USB={USB Analyzer}==>DAC/Conveter-->Prism dScope III.

Then hanging onto to the DAC was my TEK Scope which can decode I2S and my Wavecrest DTS and a Standford 760 FFT analyzer which I use to test power supplies as it is capable of full range 1nV readings.

So in this test I compared software programs which were bit true and sound different and also some USB cables which sound different and of course file types which sound different. I have like 200 hours in testing.... so far I can't see any difference.

YET!!!!! 82% of the time people picked the Flat PCM file over the lossless.

John Atkinson and Charlie Hansen both said that I could have spent that time designing something cool. So for now that is what I am going to do!

USB Cables was kind of interesting as I did find some cases were the cables caused data errors and excess jitter on the USB side. While this does not have anything to do with Audio related Jitter errors it did seem to effect the data stream. Especially with Async feedback pipe and the host missing some of these which caused buffering errors.

Thanks
Gordon
J. Gordon Rankin

[Chops]

Well, just done some A/Bing on a variety of material and bitrates. Hardly any difference, if at all - maybe something very small on a Pamela Thornby hires track. My SBT will be receiving FLAC.
Chris