On Sunday 27 November 2011 01:40, Raymond Yau wrote:
2011/11/25 Alan Horstmann gineera@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.
<snip>
Thanks Raymond for avoiding this thread becoming a monologue.
b0b7d0280f977dee1bbff0a1b4cd0c50068d2371
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:-
- 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 workaround.
- 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
- 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().
- I have misunderstood some detail in the use of Alsa which is causing
this, and when corrected the issue will not occur.
Alan