Player et processus

[a supprimer merci]

Le fil que je viens de citer, qui date de 2013, réponds à ta question. Il y a d'autres contributions intéressantes sur ce sujet, et j'essaierai de les retrouver.

Voici ce que Swenson expliquait:

"The insight is to note that in my previous post I was talking about things that affect the sound that are NOT changes to the bits, but things like ground plane noise. I was trying to show that what is happening inside the computer (processor, memory acceses etc) can change the ground plane noise. Not just the amplitude but also the spectrum of the noise. I'll give some specific examples later.

Not all programs that read files and send bits to a DAC do it exactly the same way. Some may have several buffers the data goes throuigh on it's path, some may only have one or two. Some may be built using a "layered" hierachical approach with different software "modules" that call each other, where others may be fairly "flat" with just one routine that does all the processing.

The exact sequence of instructions and memory accesses is guaranteed to be different between the programs. Since it is these instructions and memory accesses that cause the ground plane noise, I hope you can see that differences in how a task is done can produce different noise.

And BTW this CAN be measured. I've built a little ground noise analyzer that can easily see the difference in the noise from different programs doing supposedly the same thing.

Now for a concrete example. Let's take a simple program that is just coppying audio data from a file to a buffer and then to an simple output port. It has two threads, one reading the file and putting the data in the buffer, and one taking data out of the buffer and putting it on the out port using an external clock to time the opperation. The first thread waits until the buffer is empty then fills it up and goes back to sleep. (in reality there would be two buffers used in a ping pong arrangement, but that is irrelevant to the issue at hand).

So lets take this program and make two copies, one which has a small buffer and one which has a large buffer. The total amount of processing is exactly the same, the code is exactly the same, but is the ground plane noise the same? NO!

In the case of the small buffer the first thread spends a fairly short period of time waiting since the buffer empties out quickly. It spends a small amount of work often. With the large buffer each time it wakes up it has to handle a lot more data, but it waits a much longer time between sessions.

So why does this matter? If you look at the "work performed by the thread" over time the large buffer version shows a very "bursty" activity, but the small buffer shows a much more uniform activity. If you look at this in the frequency domain the small buffer version is dominated by relatively low intensity at high frequencies, mostly above the human hearing range. But when you look at the large buffer version you see higher intensity at much lower frequencies that are right smack dab in the middle of the human hearing range. This latter noise is going to have a much bigger affect on audibility.

And note this was exactly the same code, just different buffer sizes. Think what can happen when you are comparing different programs that use very different program architectures.

As an analogy, think about getting a group of people from point A to point B, either using a two seater sports car or a 30 person bus. The sports car has to go much faster and more often, the bus can only take a few trips and lumber along. But the result is the same. All the people get from poingt A to point B in the same total amount of time. But if you stand at the side of the road and have to put up with the noise, is it the same? "

---

Et une autre citation de Swenson, toujours dans le même fil, qui me semble assez claire:

"What is digital?

Digital is a nonlinear system.

Take a piece of wire with a voltage on it. These days many chips use a voltage range from 0 - 3.3V. The volotage on that wire can be anywhere in the range from 0 - 3.3V, it IS in actuality an analog signal that can take on any value in that range.

We then run that intgo a circuit that applies a threshold, lets make it easy and say the threshold is at 1.5 volts. What this circuit does is any value on it's input below 1.5V produces 0V on the output. And any value above 1.5V produces 3.3V on the output.

This circuit "quantizes" the input to just two values 0V and 3.3V (of course it is not perfect, but that is the ideal behavior).

So how does this circuit get this 0V and 3.3V for the output? It is the values on the power and ground pins of the chip. Remember we were talking about ground plane noise, well the ground pin of the chip is connected to the ground plane. The power pin is connected to a 3.3V supply that usually has even more noise than the ground plane.

So when you look at the analog voltage coming out of the chip with a scope you see noise on both the upper and lower parts of the "waveform". It is never an absolutely pure 0V or 3.3V. BUT as long as this noise never gets above 1.5V for the "low" part of the signal or below 1.5V for the "high" part of the signal, the next chip in the chain can correctly interpret it as either high or low with IT'S threshold circuit. That is the basic concept of digital, because of the nonlinear behavior (the threshold) it can withstand large amounts of noise and still keep the integrity of the data intact.

This is why somany people think "bits are bits".

BUUUT, as I was trying to point out in the previous posts it's not all just about those thresholded values. The noise on the ground plane produced by the processing and transmission of those bits can affect the sound WITHOUT being large enough to change bits.

It can cause oscillator producing the timing signals to have much more jitter than it normally would, it can cause the analog out of the DAC chip to be noisier than it normally would be, it can cause any anlog output circuitry to be noisier that it normally would be.

And here is one that is a little harder to understand. What determines that infamous threshold in the digital chips? It turns out that in most chips used today it is a ratio between the voltages on the power and ground pins. Remember that both of these pins have noise on them, that means the threshold value is going to be changing as well. So what? as long as the noise on the input is not near the changing threshold, who cares? Well it comes back to that "the output is not really ideal" statement. It takes time for the signal to go from 0V to 3.3V. This is called the "ramp time" and you can easily see this on a scope. So the input signal is a ramp (with noise embedded on it!) going into a threshold that is also dancing around, what is the result? The time at which the threshold circuit says it changed from low to high varies quite a bit, this is the dreaded "JITTER".

This jitter is directly related to the ground plane noise talked about before. Note that the bits stay intact through all this! The threshold circuit can still correctly interpet the change from low to high.

This whole thing is about there being other paths that can change the sound other than just "the bits". And those paths CAN be affected by differences in how different programs process and produce exactly the same data.

That test you are bringing up is doing a digital loopback, it takes the bits from one place into another, then sends them back out and compares them, they are the same. Thats what the circuit chain is supposed to do, and it does it. BUT every one of those parts of the chain is producing noise on its ground plane, which CAN cause changes in the sound coming out of the DAC, EVEN THOUGH the bits didn't actually change.

Does that make sense? I don't know how to better explain it. "