[alsa-devel] Proposal for more reliable audio DMA.

James Courtier-Dutton james.dutton at gmail.com
Thu Jun 25 17:26:39 CEST 2009


2009/6/24 Jon Smirl <jonsmirl at gmail.com>:
> If it is so that it can write into the buffer with minimal latency
> there are other ways to accomplish that. The simplest is to just add
> an entry into ALSA core that says, play this buffer with minimal
> latency. That would let the transfer be pushed down into the specific
> driver and that driver could handle it in an optimal way.
>
"minimal latency" is not the only requirement.
Another is "play this sample at a predictable time." in order to
ensure it plays in sync with video for example.
The real problem is ensuring that the application reacts in time to
fill up the buffer before it empties. So, the ideal would be a way to
ensure that "process X gets woken just before the buffer empties". One
way to trigger this is via the sound card hardware interrupt, another
is by using the global timer to wake one up at a particular time.
Using the timer is probably better because the wake up is then more
granular, but one then needs a way to sync the timer with the hardware
clock on the sound card.
I would like a kernel scheduling api that could reliably do "wake me
up at nanosecond X" but none exists. I can do "nanosleep(X)" which
will maybe wake me up in X nanoseconds, but it is not very reliable.
Another useful scheduling api would be "make sure process X is woken
up after me".


More information about the Alsa-devel mailing list