[alsa-devel] DMA and delay feedback

[Raymond Yau]

2009/12/14 James Courtier-Dutton <james.dutton at gmail.com>

> Hi,
>
> Would there be benefit in separating the DMA and the transfer of audio
> samples to the sound card hardware from the delay and hw position
> feedback.
> For example, If the playback position is 0, the hardware has probably
> already transferred one period of the sound card.
> So, one cannot write to playback position 2 and expect it to be output
> to the sound card if the period size is 1024.
>
> 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.
> I believe that this is what the DMA interrupt indicates. One needs to
> reliably detect a missed interrupt.
> It one took this approach, one might be able to hide the "missed
> interrupt" problem.
> When the interrupt finally did arrive, we would know where the next
> free period X is, and continue writing samples to that, irrespective
> of what went wrong before.
> This would allow for auto-recovery of the audio stream without having
> to stop and start the ring buffers again.
>
> One then needs to determine how one can get accurate "delay" values
> back from all sound card types.
>

The accurate "delay" value may be different for different chipsets using the
same driver

snd_pcm_rewindable() should provide the value to rewind to the
period_boundary , if you want to play the audio as soon as possible , you
should reduce the period size

Using software mixing but unwilling to spend CPU time (power saving) and
using large period size does not make any sense at all.



> The "delay" value is used for applications like ensuring that audio
> and video play in sync.
> The problem ones at the moment appear to be the intel8x0 and hd-audio ones.
> There may be benefits from making the "delay" value return in
> nanoseconds instead of samples, particularly if gettimeofdate() is
> being used to try to produce accurate "delay" values.
>
> Kind Regards
>
> James
>