Improved audio rendering with an optimised version of memcpy (2013)

Re:Improved audio rendering with an optimised version of mem... by dom0 on Saturday April 22, 2017 @10:56AM (#14172832)

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.

[ Parent | on HN ]

Re:Improved audio rendering with an optimised version of mem... by _iiu1 on Saturday April 22, 2017 @06:38PM (#14175252)

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.

[ Parent | on HN ]

Re:Improved audio rendering with an optimised version of mem... by asveikau on Saturday April 22, 2017 @12:01PM (#14173117)

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.

[ Parent | on HN ]

Re:Improved audio rendering with an optimised version of mem... by dom0 on Saturday April 22, 2017 @01:21PM (#14173550)

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.

[ Parent | on HN ]

Re:Improved audio rendering with an optimised version of mem... by CyberDildonics on Saturday April 22, 2017 @11:03AM (#14172859)

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

[ Parent | on HN ]

Re:Improved audio rendering with an optimised version of mem... by dom0 on Saturday April 22, 2017 @11:08AM (#14172882)

Because this is about audio output?

[ Parent | on HN ]

Re:Improved audio rendering with an optimised version of mem... by CyberDildonics on Thursday April 27, 2017 @08:47PM (#14216080)

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

[ Parent | on HN ]

Re:Improved audio rendering with an optimised version of mem... by beojan on Saturday April 22, 2017 @05:06PM (#14174800)

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?

[ Parent | on HN ]

Re:Improved audio rendering with an optimised version of mem... by Dylan16807 on Saturday April 22, 2017 @05:34PM (#14174949)

"codec" here is the sound card.

[ Parent | on HN ]