My assumption is that with any of these formats, the bits being delivered are the same and timing is the real issue. I agree that in the past it was likely that a lot of activity on the PC could affect the sound, mostly because of timing (jitter) issues. But with the use of async USB the activity on the PC seems to be a real secondary issue. As long as the buffer is full and the activity on the PC is relatively low, it seems that the aysnc USB is the determining factor. I use a PC with a very low end processor, and running FLAC through J River, the CPU hardly goes about 5%. If the FLAC decompression is a problem on a system, it is probably because there are too many other things running. Although, as I said, using an async USB converter/DAC should minimize that effect. There can still be noise issues (like small ground issues) but that should not be affected by the minor differences in processing time to decompress files. I am of the mind that "everything matters", but with properly done async converters/DACs, it seems that the other effects can be extremely small. That said, there are always people who say they hear differences in everything. I would suggest converting a few of your wav files to FLAC and listening. dBpoweramp is a good converter and it has a free version.
What hardware/software are you using? |
Al - I agree that minimizing system changes is a good practice, as is removing unnecessary software and processes. I take a different route from many - I use a Netbook with Windows 7 Starter. There are very few processes running, not even virus software (which is OK because it is a dediated system and I almost never have it on the Internet directly). You can even turn off networking if you have the files local. I still think these tricks are less important with a good aysns USB converter/DAC. I use a async USB converter and a DAC that does its own reclocking, so hopefully I am immune to PC induced jitter. If you have galvanic isolation you can elimiate other types of noise also. Unfornately, when people hear differences it is very difficutlt to find out why. |
Steve - I am using flac files, running J River from memory and with less than 5% CPU usage on Windows 7 and an async USB converter. Do you still think that the PC cannot keep up with a async USB converter in that case? I would guess J River can keep the memory buffer full. Are you suggesting that there can be enough latency in WASAPI event mode to cause timing problems with an async USB converter? |
First, sorry for moving the discussion to the age old jitter, timing discussion.
Steve - I do understand everything that is going on. I belive the flac codec is filling a buffer, in my case the memory buffer for J River. I am assuming that J River decompresses the flac before it goes into memory, but that might not be the case.
If the audio stack delivers in real time, rather than through a buffer, then the question seems to be what the async driver (like the M2Tech one you use) is actually doing. My assunmption was that the async driver is drawing from a buffer, not from real time delivery of data from the Windows audio stack. That may be incorrect. 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. It is a complicated process. I probably just do not have enough detail on the audio stack/asyn driver to understand why flac decoding (or any other running process) should interfer with the async driver timing.
I am not trying to be argumentative. I just do not understand the internal details of what is actually happening.
I do not hear a difference between wav and flac files. But I believe my DAC also reclocks so that may be the determing factor. |
"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? |
Steve - It seems like what you are describing is a timing problem that comes from the competing flac decoding and audio stack processes. How does that timing issue get passed to the DAC. As I understand it, the async USB is suppose to control the timing of the data received by the USB async converter using its internal clock and it takes the computer timing out of the process. If their is a timing error/latency from the audio stack and flac converter competing for run time that is coming through the aysnc USB converter, then it seems like the async USB converter is not effectively controlling the timing of the data. Are you suggesting that the run time issues make the aysnc USB process not work properly? If you think the aysnc USB process is working properly, then why would the flac and audio stack processes introduce timing error in the aysnc USB device? |
The idea that the FLAC decoder produces wrong numbers is just not credible. People have repeatedly shown that the compression/decompression algorithms works. And, computers very, very seldom make computing mistakes. If each time you opened a spreadsheet it produced different results, people would not use them. If there is one thing that a computer can do it is do computations correctly. If people think that the computer is regularly doing the FLAC computations incorrectly and in a random manner, then I would love to see some actual proof of that. I just do not think it happens.
So, others issues for audio seem to be electrical noise and timing. Electrical noise, for example grounds, can potentially be an issue. That is why people are building galvanic isolation into higher end devices - to break the electrical connection between the PC and the DAC. Of course, electric noise is also present in network players, it just is not tied to the PC.
That leaves timing. Digital audio depends on precise timing of each sample. Before aysnc USB, the timing was problamatic and jitter was a real issue. That is why I keep coming back to aysnc USB. If it works are advertised, the jitter should be very low and independent of the source format. If someone can explain why the source format processing influences the final timing in a aysnc USB device, then I am all ears. I admit to not knowing the exact inner workings of the aysnc code (very few people do). But if it works as advertised, then FLAC decoding should not be an issue with its timing.
I agree that networked solutions can provide better isolation that direct connections. Remember, I am not talking about audio streams in general, but the difference between FLAC and WAV files. I am not willing to say that computers routinely make computational errors when compressing and decompressing FLAC files and therefore WAV files are better. If people think they hear a difference, that is up to them. But I have yet to hear a detailed explanation of why that happens that makes sense.
Time to get ready for Thanksgiving. |
Al - First, I agree that proper setup of the PC is necessary, including not letting the CPU performance fluctuate, as you point out. I should have added the caveat the the PC is well set up, which I agree is not always the case.
I agree that there is a potential for noise issues without isolation. That is why various isolation technics are being used. Any extra noise should not affect the left/right data bits. The amount of processing used to decode a FLAC file is really minimal. I just do not see that minor extra processing having much effect. When I compare playing WAV files to playing FLAC files I do not see any noticible fluctuation in CPU usage. It must be there, but it is pretty minimal, at least on my system., where usage is typically under 5%. As I said, if the async USB is doing what is advertised to do, then that noise should not affect the timing. If the noise interferes with the async USB circuits in the converter, then differences are certainly possible due to jitter. So fair enough, it is possible. I am just not sure there is enough noise from unpacking the flac to make an audible difference.
It seems that people using wireless solutions would not see the effects of this noise, unless it goes through the power cords.
I must say, it would be very difficult to actually measure any of these differences on the circuitry of the converters and DACs.
The 35 pound Hubbard squash is cooking. The French Canadian meat pies (Tourtier)are getting started, and the traditional home made vegetable soup for Thanksgiving lunch is just getting going, although we made the stock yesterday. Starting to smell good. |
