On Mon, 2010-06-28 at 09:47 +0200, Jaroslav Kysela wrote:
On Sat, 26 Jun 2010, David Dillow wrote:
When using poll() to wait for the next period -- or avail_min samples -- one gets a consistent delay for each system call that is usually just a little short of the selected period time. However, When using snd_pcm_read/write(), one gets a jittery delay that alternates between less than a millisecond and approximately two period times. This is caused by snd_pcm_lib_{read,write}1() transferring any available samples to the user's buffer and adjusting the application pointer prior to sleeping to the end of the current period. When the next period interrupt occurs, there is then less than avail_min samples remaining to be transferred in the period, so we end up sleeping until a second period occurs.
This is solved by using runtime->twake as the number of samples needed for a wakeup in addition to selecting the proper wait queue to wake in snd_pcm_update_state(). This requires twake to be non-zero when used by snd_pcm_lib_{read,write}1() even if avail_min is zero.
Signed-off-by: Dave Dillow dave@thedillows.org
Thanks. It looks like another way to get things right. I applied your patch to my tree.
I think we should probably better define the semantics of read/write for sizes < avail_min, == avail_min, and > avail_min. As it is, I fear that this patch makes things worse as I hadn't thought through all of the cases when I posted it. If you've not pushed, please revert. If you have, then it improves one case, but let's makes sure we get the others correct before it hits the mainline.
Dave