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@xxxxxxxxxxxxxx>
>
> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
