Hacker News Reader

Comment by dom0 | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com