Re: emu10k1 bug and patch (0.9.0rc7)

[Arnaud de Bossoreille de Ribou <arnaud.debossoreille@via.ecp.fr>]

On Thu, Feb 13, 2003, Jaroslav Kysela wrote:
> On Mon, 10 Feb 2003, Arnaud de Bossoreille de Ribou wrote:
> 
> > 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.
> > 
> > So the emu10k1.patch file attached fixes the problem and seems not to
> > introduce new ones.
> 
> Please, could you try this patch, if it also fixes your problem? Thanks.
> 
> 
> Index: emufx.c
> ===================================================================
> RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/emufx.c,v
> retrieving revision 1.26
> diff -u -r1.26 emufx.c
> --- emufx.c	31 Jan 2003 15:21:03 -0000	1.26
> +++ emufx.c	13 Feb 2003 20:29:55 -0000
> @@ -532,7 +532,7 @@
>  	if (diff) {
>  		if (diff < -(snd_pcm_sframes_t) (runtime->boundary / 2))
>  			diff += runtime->boundary;
> -		pcm->sw_ready += diff;
> +		frames += diff;
>  	}
>  	pcm->sw_ready += frames;
>  	pcm->appl_ptr = appl_ptr + frames;
> 
> 						Jaroslav

It doesn't. sw_ready is negative (or above 2^31 as you like).

I think it has nothing to do with runtime->boundary since the 2 appl_ptr
are very close. The difference is always one period but I wonder why
runtime->control->appl_ptr is above pcm->appl_ptr. Is this because the
hardware has played one period that it shouldn't ?

On the other hand if the difference is really always of one period the
fix consists in conditioning the diff calculation with a
"if(frames != 0)" so that sw_ready never reaches its lower boundary.

Regards,

-- 
Arnaud


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf