[alsa-devel] DMA and delay feedback

[James Courtier-Dutton]

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
fashion.
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.

James