[alsa-devel] _mmap_playback_avail() short (was: Default device XRUNs with perriods=2)
gineera at aspect135.co.uk
Mon Nov 28 12:03:00 CET 2011
On Sunday 27 November 2011 01:40, Raymond Yau wrote:
> 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.
Thanks Raymond for avoiding this thread becoming a monologue.
Thanks; there are a few threads that discuss problems with avail_min, periods
== 2, and timing inconsistencies. The more I read over and again it seems
rather a can-of-worms.
> Do you require the sound card give you accurate playback position ?
No. Just accurate playback (or capture). But reliably, on any system,
without hardware-specific tweaks, 'out-of-the-box'. Ideally with the
potential for reasonable latency if the user requests that. And not
necessarily only on the 'latest' Alsa versions.
As per this quote from Jaroslav in one of the threads:-
"But it's right that most of simple applications and use cases expect that I/O
transfers will work even with 2 periods.
That does not work in the 'default' circumstances I am describing here, on
several hardwares on any Alsa version.
> 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
Yes, this is the sort of thing that makes it more difficult to create a good
> > 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
My current thinking (but could change) is for this one; if poll returns
successfully, and the revent is not POLLERR or POLLHUP, don't check for
non-zero (POLLIN or POLLOUT) but treat it as a valid period event regardless
and perform the processing, checking avail_frames etc.
Such an approach effectively removes the check on
snd_pcm_mmap_playback_avail() in the function snd_pcm_direct_poll_revents().
> > 4. I have misunderstood some detail in the use of Alsa which is causing
> > this, and when corrected the issue will not occur.
More information about the Alsa-devel