[alsa-devel] _mmap_playback_avail() short (was: Default device XRUNs with perriods=2)

[Raymond Yau]

2011/11/25 Alan Horstmann <gineera at aspect135.co.uk>:
> There's been no take-up on this, but I am seeing a consistent issue, with Alsa
> from 1.0.12 to 1.0.24, on 2 different machines with different audio hardware
> which will need to be worked around one way or another, and I wonder which is
> best?
>
> The problem is with poll revents from default device when it includes SR
> conversion and dmix.
>
> On Thursday 03 November 2011 10:03, I wrote:
>> After several days dissecting, mainly with printf's, I have tracked the
>> events that cause the problem I originally posted about with Portaudio
>> playback to the default device at 44100Hz.  Could you confirm that the Alsa
>> behaviour is what should be expected, please?
>>
>> It seems that at a period boundary event snd_pcm_mmap_playback_avail() may
>> not return a full period size, but is a few bytes short.  If avail_min is
>> set to one whole period (which Portaudio at present does),
>> snd_pcm_direct_poll_revents() zeroes the revent due to the check of
>> snd_pcm_mmap_playback_avail() against avail_min.  POLLOUT is therefore not
>> indicated, and the app does not write any data, causing an Xrun.
>>
>> However, if the absence of POLLOUT is ignored, calling
>> snd_pcm_avail_update() at that time returns a full period size.
>>
>> This only seems to happen on the default device when playing at a sample
>> rate not corresponding to the dmix rate of 48000, presumably due to the
>> plugins/conversions?
>>
>> The solution from the Portaudio point-of-view is to set avail_min lower,
>> but I wanted to check with you that the values being returned are sane.
>
> This only works with the older Alsa versions, since avail_min cannot be set to
> less than period size more rrecently.
>

b0b7d0280f977dee1bbff0a1b4cd0c50068d2371

Do you require the sound card give you accurate playback position ?

snd-ymfpci only update hwptr in 5.3ms intervals

it seem that snd-usb-audio update hwptr in 1ms


> It seems the options are:-
>
> 1. Use 3 periods and accept worse latency, always filling with avail_frames
>

snd-ymfpci has periods_min 3
and there are sound cards with periods_max = 2

> 2. Use 3 periods, but only fill partially, so there is, for example, always
> one period of space after filling, and at a poll nearly 2
>
> 3. Ignore the absence of POLLOUT or POLLIN flag, and instead treat the zero
> revent as good, check avail_frames and fill the buffer
>
> 4. I have misunderstood some detail in the use of Alsa which is causing this,
> and when corrected the issue will not occur.
>
> Assistance to solve this would be greatly appreciated, since ultimately I
> would like to see Portaudio work well without issues on Linux/Alsa.  If more
> info would help, please ask.
>
> Thanks
>
> Alan