I believe the run-time problems cause the FLAC CODEC to malfunction.
I do not believe it has anything to do with async USB. My customers told me that this happens even with my older adaptive USB interface.
Steve N.
Empirical Audio |
Mapman - Even though I sell only USB interfaces, and I'm able to achieve good performance, I believe that the ultimate solution that takes the computer out of the equation is networked audio streaming.
There are several proprietary networked systems available now, but the SQ of these leaves a lot to be desired IMO. Because they are proprietary, expert developers cannot create either devices or DSP software for these. The ultimate goal should be a ubiquitous player and an open system. I am currently submitting proposals to enable this for the industry.
Steve N.
Empirical Audio |
Okay, here's my hypothesis:
When using networked servers, such as Sonos and Logitech, the decoding processes of FLAC and ALAC have plenty of time to execute because the other processes are not real-time. This is because the networked stream is packetized and transmitted very quickly, and does not get involved with the S/W audio stack in the computer. The data processing in the computer is minimal and happens very quickly making the latency very low for these transfers. This allows the CODEC to run as slow or fast as it needs to run to achieve accurate results. As a result, the sound quality differences with these lossless formats is usually minimal if even detectable when using network protocol.
On the other hand, when you use Firewire or USB for data streaming, some of the audio stack is involved and the CODEC must run in real-time and keep-up with the stream rate. Because the audio stack creates a lot of latency, even when playing uncompressed files, there is evidently not much time left for FLAC decoding to keep up with the bit stream. As a result, the timings are very tight and sound quality suffers as a result. This is why I believe on a resolving system using USB or Firewire, FLAC files sound like listening through a tunnel and the same FLAC uncompressed to .wav sounds normal. I dont know if this is a result of poor programming for the FLAC and ALAC CODECs or maybe just the way that they execute when they are competing for resources and repeatedly queue and stall in the execution sequence. With multi-threading in computer OS now, these applications dont run continuously ever.
There is a lot of anecdotal evidence to support the above hypothesis. I have no technical proof however.
Steve N.
Empirical Audio |
DTC - I believe the problem is latency and interference, not CPU usage. When the core audio stack interferes with smooth execution of the FLAC CODEC, this is where the problems start.
Has nothing to do with async USB converter and delivering data to that.
Have you tried changing the FLAC file back to .wav with dbpoweramp and compare the two tracks by listening?
Steve N.
Empirical Audio |
"Do you have enough details on the async drivers to know if process swapping can actually effect the async driver significantly? If there really is a problem there, then improving the clocks in async converters should not be important."
Improving the master clock in async USB converter is always worthwhile, even if your DAC resamples. Resampling of course puts the jitter of the resampling clock on the data stream, so it can make things worse for sure.
The clock in the USB converter is orthogonal to the problems with FLAC decompression I believe. They are both important effects.
Steve N.
Empirical Audio
Steve N.
Empirical Audio |
Mapman - whether you can hear these differences or not is highly dependent on your system. For instance, if you use an active preamp of any kind, you may not hear a difference. Preamps add a layer of noise, distortion and compression that is significant. Until you run without a preamp (and I dont mean with a resistive passive linestage), you will not realize how much grunge your pre actually adds.
I always believed that my highly modified Mark Levinson Pre was really transparent. Then I built a DAC with a good volume. Boy was I wrong. The pre is now gathering dust...
Steve N.
Empirical Audio |
Mapman - that figures. With networked audio, you are less likely to hear differences. Data is just data, not audio data as with USB or Firewire, so the audio stqck is less involved, if at all. Jitter from the computer is also a non-issue with network playback. Only the end-point device jitter and clock matters.
Steve N.
Empirical Audio |
""Malfunction"? Are you saying that the 16/24 bit data for each sample is incorrect? That the data that comes out of a flac decode is different that the wav data?"
Yes, I believe its incorrect when the decoding is done on-the-fly.
Steve N. |
"The idea that the FLAC decoder produces wrong numbers is just not credible. People have repeatedly shown that the compression/decompression algorithms works."
Yes they have, but only staticly, never real-time.
Electrical noise in the PC is not the cause of these differences, and jitter is not the cause either. Noise will not change significantly with different tracks or different formats. Jitter is a non-issue with Async USB.
Steve N.
Empirical Audio |
EDorr - are you using a USB interface? What player S/W? Are you using a Preamp? What ripper did you use?
All of these must be optimized in order to get stellar results, and to hear these differencees easily.
Steve N.
Empirical Audio |
"The noise transients I am envisioning are associated with the abrupt SWITCHING of cpu clock rate, and in some cases voltage as well, that unless disabled by the user will occur as processing tasks intermittently start and stop."
Huh? There are certainly differences in power in the computer when there is highly CPU intensive calculations ocurring, but as noted, we have not seen this in the CPU usage numbers.
Has anyone looked at the CPU usage graphs while running .wav compared to FLAC?
Steve N.
Empirical Audio |
Al - Just another datapoint telling us that the CPU execution is having an effect on sound quality.
This is why I recommend only Mac, and only Amarra 2.3.x. This combo is simply killer. My PCs are not even close.
There are still SQ obstacles even with Mac, but they are minor IMO.
Some improvement can be had by using SSD rather than hard disk for instance. Also better power supply for a Mac Mini seems to help. I dont know why... The mach2music.com works well if you dont want to fuss with it.
Its good enough stock though, that I have not bothered with these tweaks yet. I use a 2009 Mini with Snow Leopard on it.
Its much more important that you use a good USB interface with good clocks.
Steve N.
Empirical Audio |
