[alsa-devel] DMA and delay feedback

James Courtier-Dutton james.dutton at gmail.com
Mon Dec 14 16:34:39 CET 2009

2009/12/14 pl bossart <bossart.nospam at gmail.com>:
>> For transfer purposes, one only needs to know that DMA transfer is
>> complete on period X so that period X can now be over-written.
> That's the 'traditional' view. ALSA is now used in different ways.
> PulseAudio sets a timer and relies on snd_pcm_avail() to query how
> many samples it can write to the ring buffer, the notion of period
> isn't used at all. I think we could use additional information in the
> way the hw_ptr position is reported, namely hints on how precise this
> information is and the granularity of the updates.
> - Pierre

There is a problem with getting snd_pcm_avail() accurate from a
hardware perspective.
I was trying to come up with a method for letting the application
(pulseaudio) know how much data it can write in a more accurate
An extra bit of information is also useful, and that is some
prediction of when one should next write samples after this write.
One then has a sensible value to use for the timer.
People use snd_pcm_avail for different tasks, and I was trying to
break the use cases out and analyse each one it turn and see if a
better API interface could result.
The use cases are:
1) Deciding when and how many sample to write and when one is likely
to need to write again.
2) Syncing the samples to a video stream or other time source.
There are other requiremets:
1) Having the application buffer size different from the hardware buffer size.
2) Having the application sample rate different from the hardware
sample rate, and thus doing resampling.


More information about the Alsa-devel mailing list