At Mon, 28 Jun 2010 16:11:21 +0200 (CEST),
Jaroslav Kysela wrote:
>
> On Mon, 28 Jun 2010, David Dillow wrote:
>
> > 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.
>
> I don't see any drawbacks in your solution. When I/O size is greater than
> avail_min, the behaviour is same as in previous code (avail_min is used
> for wake_up). For smaller I/O sizes (requests are not aligned to period
> size), each period interrupt will cause a wake up for the application
> task. In this case, the application may do own optimization of I/O
> transfers (sizes).
I pulled to my tree now, too.
(sorry for the late response, as I've been on vacation.)
It looks good to me. Let's see whether it breaks something ;)
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
