12.11.2014 18:25, David Henningsson wrote:
On 2014-11-12 14:15, Peter Meerwald wrote:
From: Peter Meerwald <p.meerw...@bct-electronic.com>
snd_pcm_mmap_commit() actually transfers the memory area prepared by
snd_pcm_mmap_begin(),
it returns the 'count of transferred frames' which should be equal to
the number of frames
returned by snd_pcm_mmap_begin()
however, this identify is not checked and the number of frames
prepared are accounted for,
not the number of frames commited -- this is wrong; the ALSA example
codes bothers to
check snd_pcm_mmap_commit()'s returned number of frames
this patch outputs a warning and uses the commited number of frames to
update the bytes
read or written, resp.
It's not that easy, I think...
In case you get fewer frames written, you should retry the mmap_begin +
mmap_commit cycle but *without* calling pa_sink_render_into_full, and
only with the remaining frames. Right?
I'd question that. The alternative (but not something that I insist
upon) is that pulseaudio should just sleep, as it would normally do
according to its timer-based scheduling logic. Next time it wakes up, it
should render some more frames (so that it has both old-unwritten and
newly-rendered frames), and write (via mmap) as much as possible.
--
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
