12.11.2014 18:25, David Henningsson wrote: > > > On 2014-11-12 14:15, Peter Meerwald wrote: >> From: Peter Meerwald <p.meerwald at 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
