At Thu, 13 Feb 2003 20:57:40 +0100 (CET),
Jaroslav wrote:
>
> On Thu, 13 Feb 2003, Takashi Iwai wrote:
>
> > At Mon, 10 Feb 2003 18:21:12 +0100,
> > Arnaud de Bossoreille de Ribou wrote:
> > >
> > > Hi, I discovered a bug in the emu10k1 driver which I'll explain here:
> > >
> > > I was developing an application which uses the timestamps given in the
> > > status of the device to send S/PDIF data to it. This app worked pretty
> > > well except that sometimes I heard sound discontinuities and then a
> > > constant time delay between the sound and the video.
> > >
> > > I finally found where was the problem, my results is based on the
> > > emu10k1-debug.patch file attached. The "frame" argument is equal to 0
> > > when the app gets the status of the device. With this patch applied I
> > > saw some output on the console exactly at the same time the bug occured.
> > > Adding a "else" after the "if" to prevent sw_ready from being updated
> > > fixed the problem and the output looked like
> > >
> > > ----------------
> > > plop 0 -1536 A B
> > > plop 0 1536 B A
> > > ----------------
> > >
> > > where B == A - 1536 (1536 is the period_size). These two lines were
> > > repeated a few times during playback.
> > >
> > > So the bug looks like a signedness problem since sw_ready is unsigned
> > > and there is a while(sw_ready > 0), which explain the constant delay,
> > > next in the "snd_emu10k1_fx8010_playback_transfer" function.
> >
> > this is because of the incorrect check of boundary-wrap.
> > the comparison below must be <= instead of <.
> > (or, it can be simply "diff < 0".)
> > if there only two periods, the original code cannot detect the
> > boundary-wrap.
> >
> > if (diff) {
> > ==> if (diff < -(snd_pcm_sframes_t) (runtime->boundary / 2))
> > diff += runtime->boundary;
> > pcm->sw_ready += diff;
> > }
> >
> > sw_ready should be unsigned safely.
> > please try the change above with the unsigned sw_ready.
>
> Not really. Note that the application can move the appl_ptr backward
> (using snd_pcm_rewind()). The problem is that pcm->appl_ptr is updated
> wrongly, thus calling function with frames == 0 twice or more causes
> different results. I'm working on a proper fix.
ah, rewind take the appl_ptr back...
regarding to another appl_ptr update:
in pcm_lib.c snd_pcm_lib_read1/write1(), appl_ptr is set to 0 if it
comes over boundary.
appl_ptr += frames;
if (appl_ptr >= runtime->boundary) {
runtime->control->appl_ptr = 0;
} else {
runtime->control->appl_ptr = appl_ptr;
}
i'm not sure it's always safe (whether frame increment is aligned to
the boundary size). is there problem to do like below?
if (appl_ptr >= runtime->boundary) {
runtime->control->appl_ptr = appl_ptr - runtime->boundary;
} else {
...
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
