Reducing jitter for file playback is easy. Just use a huge buffer. Done. Latency doesn't matter because the whole file is available ahead of time.

Even if this did matter, it's still bullshit. Memcpy isn't going to add latency and jitter over some "optimized" copy routine. And C++ new certainly isn't going to be better than malloc, when it's almost certainly calling through to malloc.

If the song was recorded in 1991 and you're playing it now, that's 26 years of latency, no matter what.

One year longer and it would not be latency anymore, it would be hammertime.

(Sorry)

Audio codecs use memory-mapped ring buffers; as long as the driver's write pointer stays ahead of the codecs' read pointer there is no way to add jitter. Note that the codec doesn't care about the write pointer, if the driver forgets to update the buffer, the card will just play it over and over again. Sometimes that happens when a computer wakes up from stand-by. The result is quite characteristic.

you are describing a buffer over/under run. jitter is when a stream of serial audio data (such as most external usb/firewire/etc audio interfaces end up receiving) is not time-aligning it's frames/samples correctly with the clock of the codec (which should be the master clock) or other situations where the clocking of playback/recording differs from the derived "clock" of the streams boundaries.

The concepts you are mentioning (DMA and ring buffers) are heavily used but I don't think you have the layering right. In all APIs I have used, the codec library itself works with contiguous buffers typically on the heap, which end may up being copied into ring buffers or DMA buffers I will give you, but that is one abstraction above or below.

I meant the hardware with audio codec, though technically it would be the audio controller which has the buffers and control registers (which may/may not be the same chip, depending on the exact make, e.g. in HD Audio the controller is in the chipset, and the codec is a separate chip). Sorry for the confusion.

Why isn't it the audio codec's write pointer and the driver's read pointer?

Because this is about audio output?

I had that part figured out for myself, thanks for being patronizing while adding nothing.

Right, so the codec decodes the audio and writes it into the buffer, and the sound card (or driver) reads out of that buffer and plays the sound. Where am I going wrong?

"codec" here is the sound card.

Back in 1997-8, I ran across custom hardware that used this strategy to directly transfer large volumes of ADC data from the sampling hardware to a disk array. It made absolute sense given the the data volumes involved. (100-200MB/sec to persistent storage, which was a lot for commodity hardware back then.)

Audio is full orders of magnitude less data and this is on hardware that's 20 years newer. With any reasonable buffer size this is a slam dunk, unless perhaps you're really concerned about latency.(In which case automatically streaming multiple megabytes of audio data across DMA isn't going to help you either.)

>To people making fun - this is not about creating audio files, but rather about techniques to reduce latency and jitter when playing audio files.

They are more like techniques for creating April Fools jokes...

>For example, one of the responses proposed pre-loading a large fully-rendered audio segment onto a DMA buffer to remove the CPU from the latency-sensitive pipeline entirely.

You missed the fact that that response was taking the piss of the initial post...

"Taking the piss of" is not comprehensible in my (middle american) dialect. Please elaborate.

It may be also be used to refer to a ruse whereby a person is led to believe a plainly unbelievable fact for the purpose of ridicule of the subject, e.g. "Are you being serious?" "No, I'm just taking the piss."