Quote:
DA conversion is a delicate process.
Claims about theaudible threshold of jitter varies but we probably talk nano or even pico seconds.
I think it is perfectly possible that electrical activity going on inside a PC disturbs the clock of the sound card so maps itself into sample rate jitter.
Increased system activity will decrease the sound quality.
This is pretty much like having a video card and the more system activity, the more your screen starts to blur!
One might argue that if sound quality fluctuates with system load, this indicates a design flaw.
As a consequence, on a well designed system you won’t hear any difference and on the ones with a crappy sound card, you do.
What do we need?
Somebody with that bloody expensive gear able to measure the jitter on the digital out when playing WAV or FLAC.
All that is after the FLAC decoding and I don't see how it could be affected by the extra effort needed to decode the FLAC.
This is how I view it as a software engineering exercise:
You have buffer in RAM that is implemented as some form of a
queue data structure. A queue is a First In First Out type of structure. It's like waiting in line at the bank. The buffer would hold PCM sample data. It could be any size we want, but lets just make it big enough so it can hold a maximum of 5 seconds of audio.
We have one thread that reads the file from the disk, decodes the data to raw PCM, and puts that data in the queue (the buffer). The thread monitors the buffer and fills it as needed. If the file is an MP3 it decodes the MP3 to PCM. If the file is FLAC it decodes the FLAC file to PCM. If the file is WAV it decodes the WAV to PCM.
We have another thread that takes data from the buffer and plays it. It plays whatever is in the buffer till the user hits pause, stop, or skip.
So we've got two threads going. One decodes the audio and fills the buffer with PCM data. The other thread plays PCM data from the buffer.
The thread reading files has an easy job. It is going to be idle much of the time even when processing FLAC or APE or MP3. It isn't too time sensitive. All it has to do is keep up with playback and fill the queue. It can fill the buffer, be lazy for a few seconds, then fill the buffer again. Easy.
The playback thread is where the time critical stuff is. That thread can't be lazy. It needs to be right on the ball. It can't get delayed. It has to stream data in real-time. Any delay can cause an audible glitch. This thread is where the brains and the critical processing in the audio player will be. If the the software is capable of causing added jitter in the data or cause playback problems this is the thread that would be at fault.
So two threads. One that reads, converts, and fills the buffer. It has an easy job. Not much it could do to cause jitter or other artifacts other than causing reads from the hard drive. The other thread is where the critical processing is for playback.
Given a setup like that I don't see how the processing to convert FLAC to PCM vs. WAV could have any effect on the audio quality at all. The thread that does that work is separate and that thread has a comparatively very easy job and nothing overly time critical.
The playback thread is where the time critical stuff is. And that thread wouldn't even need to know whether the PCM data that it is playing came from an MP3, WAV, FLAC, APE, AAC, or some other format. All it does is see PCM data in the buffer and play it. It doesn't need to know where that PCM data came from. As far as the playback thread is concerned there is no difference between FLAC, MP3, and WAV. No difference.
That's a basic simplified software view of audio playback. FLAC and WAV get treated the same.
As for measuring the jitter with uber-expensive gear. That would be an interesting experiment. I wonder just how much the application code can affect jitter as long as the application level code is being at least reasonably competent about playback. I'd think that the driver level and OS level code would be more likely to do things that ultimately affect jitter. Driver and kernel code doing things like changing CPU speed and power on the fly, blocking application threads during interrupt processing, background disc reads, network drivers being CPU and interrupt time hogs, things like that. Things that aren't in direct control of the application.
