>Yes, while we have the mmap_begin function limiting the transfer count and
>application knows how many samples should be filled, the reducing the
>counf of channel is really not necessary. I think that it would be better
>to avoid to do this by programmers, because we can use the mmap_commit
>size count for some internal purposes
wrong! i had to fix a major, major bug in my audioengine and the JACK
code last week that was caused by this very detail. if there is an
assumption that we process audio in chunks of up to period_frames at a
time, then its not OK to process it using the value returned by
snd_pcm_mmap_begin(), which may indicate more data/space is available
than period_frames.
there a choice to either call the commit function each time we
actually *do* process data, or only to call it after all the "sub"
processing has finished (i.e. we've processed as many frames as
snd_pcm_mmap_begin() indicated at the beginning. it seemed to me that
the former idea was more robust, since it reflects the state of the
system closer to the time when things actually change. so, my loop
looks something like:
while (avail = snd_pcm_mmap_begin()) {
to_do = min (avail, block_size);
process (to_do);
snd_pcm_mmap_commit (to_do);
}
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
