Audio science

[Rescator]

This is in response to memory tips for ultra low jitter, I didn't feel it appropriate to to reply to that thread directly (as my issue is not with the code but the reason/purpose of it), so into off-topic we go instead.

The slight jitter not even allowed software, the following Tips will help.

Don't use MOVQ
Use MOVNTQ, MOVNTDQ, then don't use CPU cache memory
Use MMX register[/list]

This code use for After decode process or After sound process or For Asio buffer.
Bit holding voltage rise in the memory circuit of the memory chip for ultra low jitter.
Ranking of quality : 1st MMX(movntq), 2nd AVX (vmovntdq) 3rd SSE(movntdq)[/list]

CopyMemory for ultra low jitter

That is, jitter is caused by CPU cache use.

Um! Don't you mean latency?

In purely the digital domain 318 samples (16bit or 24bit or 32bit) of audio are 318 samples always, there is no jitter.

Jitter is caused when a bit ends up as 0.99 or 1.01 instead of 1.0 (not to be confused by floating point values) and this can only happen during the analog to digital or digital to analog stage (usually in the audio chip).

And if you mean that a bit may become 1 instead of 0 or 0 instead of 1 then that is called bitrot (in case of permanent storage) or bad memory (in case of RAM), ECC RAM helps detect those though but ECC RAM is not that common in consumer systems.

The other issue is sampling rate, it is quite possible for a A/D or D/A (especially cheap chips or soundcards) to be 44100.5 Hz or 44099.5 Hz, not sure if that is due to jitter but it is related to the sampling clock being a bit "off" to put it mildly.

The only place anything resembling jitter can occur in a PC internally is in the system clock or similar, QueryPerformanceCounter relies on a clock and this may have some jitter. This is also the reason why a lot of random number code (that ad time into the mix) suggest to discard the lowest bits.


Also note that if you are doing audio processing the it's important that any parallel processing is done correctly as you do not want the samples to be output in the wrong order (easy to screw up if doing multi-threaded audio-processing).

Also note that latency is noticed much more than jitter, DirectX itself has by default 80ms latency, and the more advanced CPU instructions and caches if used correctly can reduce the added latency of audio processing on top of the latency of the audio pipeline.

(ABX tests have been done for jitter and without anyone hearing jitter, Hydrogen Audio may be a bit anal about their strictness of statements but their focus on scientifically re-producible results is admirable).



Also (and this is just my own opinion) the damage doe to audio due to clipping and compression just to make it sound louder is far worse than any latency in a modern PC or any jitter or noisefloor that may exist on modern A/D and D/A chips.
You can't hear the full 16bit audio range anyway as that is a wopping 96dB and listening to levels above 85dB for more than (an hour?) can permanently damage your ears, as you go above 85dB the time needed to damage your ears gets even shorter.
To hear the lowest bits of 16bit audio you would need the volume cranked to 96dB, on average most humans prefer a listening range of 30dB which means that it is the upper 30dB we listen to the most which is the topmost 5 bits relatively speaking. Music using the full 96dB would be uncomfortable to listen to and only natural unprocessed recordings have those dynamic ranges (usually).

The best way to play back audio will always be to have a bit accurate decoder (only possible with lossless formats like FLAC or WAV PCM 16bit/24bit), and ensure that there is no audio buffer overflow/overflow and that any latency is minimal and that no adjustments are made to the volume and no other processing.
essentially if you take a FLAC and decode and play it and use the optical out and then back in through the optical in and do a bit comparison and it should be a perfect match as long as you align the recording correctly (this is where jitter in the A/D and D/A might manifest if detectable).

PS! You advice against using MOVQ but in your memory rewrite code you are using MOVQ. I've seen a lot of other odd code related to your player as well, often doing unnecessarily things, using extra CPU or memory when not needed. An Audiophile not only want bit-perfect audio, they also want minimal latency and processing otherwise (actually any form of processing is taboo, for some audiophiles that even include digital volume knobs/sliders).

I highly advice watching http://www.xiph.org/video/ I try to re-watch those as often as I can to make sure I remember as much as possible. The first time I sw them it was an eyeopener, and I still find them an interesting primer to digital audio.

[oryaaaaa]

This tips is using for hi-end audio only.

[Bo Marchais]

Well, in Windows those fixed sampling rates are not as fixed as you might think.

He's not crazy. At least, not because of this code sample. I have no opinion on anything else...
He's just working at the very limits of his english language comprehension - and possibly at the limits of his own knowledge.
It's too bad his knowledge of english isn't better.

Latency is actually the amount of time it takes to respond to a request to do something. In memory, if I ask to read a byte and it takes 30ms to give it back to me, the latency is 30ms.
Now, really, that's almost always an upper limit - it might take less, it might take a little more, but 95% of the time, I'll get that byte in 30ms or less.

Jitter describes variation in that latency (well, more or less) - if it takes 20.99995 the first time and 21.00005 the next, and then 19.93456 the time after that, obviously there is some variation - and that's what jitter describes (again, this is an abstraction, and YMMV) in this context. When you sample things, timing is very important. If it isn't precisely the same every time, you can get errors in your math that result in "ghost noise" - spurious signals measured that weren't there in the first place.

I haven't looked carefully at the code, but the concept is sound. However, doing this on a program running under windows probably negates some (if not most) of the benefit.
The technique is more suited to embedded programming. It's possible that he has resolved some of the drawbacks, but again, only the people who really need this could know why low jitter is important.
Jitter describes tiny but important variations in the sampling period, and it absolutely can be crucial to the outcome because it introduces artifacts and aliasing to a sample. If he's doing math or post-processing, eliminating such errors at the source is the best practice.

Go look at the wikipedia entry on jitter for more details.

[heartbone]

I believe this thread is a good place to post this.
I was looking for another replacement mp3 player for my daughter.
Those ~$25 Chinese units although sounding good, only last about a season or two before they wear out due to a mechanical or electronic defect.
While looking for a better unit I encountered some of these examples of audio science.
"The rate of the Jitter is lower than 5ps"
I'm thinking this is referring to pico seconds, as in 1 trillionth of a second.
I'm thinking there's no audible difference between it and the thousand times worse < 5 nano second Jitter.

I had decided to spend twice as much this time and was going to buy a SanDisk player based on what I had read last year,
but after reading recent comments about general disappointment with the latest generation of the SanDisk players,
I decided to buy two different recent Chinese models, and cut the player's installed RAM to 8GB from 16 GB.
This one for my daughter,
and this one for me as my 9 year old eTEC mp3 player's battery isn't holding much of a charge these days.

If they turn out to be good players, they can be upgraded with Micro SD Card memory.
I have some hope that hers will last a year, my cheaper unit will be used much less and should last me a bit longer.
But if her unit turns out to be another 3-9 month life expectancy throwaway device,
then that $95 16GB SONY Walkman MP3 should still be on the market.
However based on the initial customer reviews for the unit, it looks like the quality of consumer grade portable audio electronics is getting somewhat shabby,
and we may just have to deal with throwaway tech until I can acquire a Colorfly player.
The previous 16GB SONY Walkman model does not seem to have the same customer complaint issues.