[PATCH] ALSA: ctxfi - Work around emu20k1 glitch to prevent buffered sound data loss

[PATCH] ALSA: ctxfi - Work around emu20k1 glitch to prevent buffered sound data loss

[Sarah Bessmer]

Occasionally, on playback stream ringbuffer wraparound, the EMU20K1
hardware will momentarily return 0 instead of the proper current(loop)
address. This patch handles that case, fixing the problem of playback
position corruption and subsequent loss of buffered sound data, that
occurs with some common buffering layout patterns(e.g. multiple
simultaneous output streams with differently-sized or
non-power-of-2-sized buffers).

An alternate means of fixing the problem would be to read the ca
register continuously, until two sequential reads return the same
value; however, that would be a more invasive change, has performance
implications, and isn't necessary unless there are also issues with the
value not being updated atomically in regards to individual bits or
something similar(which I have not encountered through light testing).

I have no EMU20K2 hardware to confirm if the issue is present there,
but even if it's not, this change shouldn't break anything that's not
already broken.

Signed-off-by: Sarah Bessmer <aotos@fastmail.fm>
Cc: Takashi Iwai <tiwai@suse.de>
---
--- linux-3.10.25/sound/pci/ctxfi/ctatc.c.orig	2014-01-09 10:12:00.000000000 -0800
+++ linux-3.10.25/sound/pci/ctxfi/ctatc.c	2014-01-09 10:32:42.000000000 -0800
@@ -433,10 +433,15 @@ atc_pcm_playback_position(struct ct_atc
 
 	if (!src)
 		return 0;
 	position = src->ops->get_ca(src);
 
+	if(position < apcm->vm_block->addr) {
+		snd_printdd("ctxfi: bad ca - ca=0x%08x, vba=0x%08x, vbs=0x%08x\n", position, apcm->vm_block->addr, apcm->vm_block->size);
+		position = apcm->vm_block->addr;
+	}
+
 	size = apcm->vm_block->size;
 	max_cisz = src->multi * src->rsc.msr;
 	max_cisz = 128 * (max_cisz < 8 ? max_cisz : 8);
 
 	return (position + size - max_cisz - apcm->vm_block->addr) % size;

Re: [PATCH] ALSA: ctxfi - Work around emu20k1 glitch to prevent buffered sound data loss

[Takashi Iwai]

At Thu, 9 Jan 2014 11:36:31 -0800,
Sarah Bessmer wrote:
> 
> Occasionally, on playback stream ringbuffer wraparound, the EMU20K1
> hardware will momentarily return 0 instead of the proper current(loop)
> address. This patch handles that case, fixing the problem of playback
> position corruption and subsequent loss of buffered sound data, that
> occurs with some common buffering layout patterns(e.g. multiple
> simultaneous output streams with differently-sized or
> non-power-of-2-sized buffers).
> 
> An alternate means of fixing the problem would be to read the ca
> register continuously, until two sequential reads return the same
> value; however, that would be a more invasive change, has performance
> implications, and isn't necessary unless there are also issues with the
> value not being updated atomically in regards to individual bits or
> something similar(which I have not encountered through light testing).
> 
> I have no EMU20K2 hardware to confirm if the issue is present there,
> but even if it's not, this change shouldn't break anything that's not
> already broken.
> 
> Signed-off-by: Sarah Bessmer <aotos@fastmail.fm>
> Cc: Takashi Iwai <tiwai@suse.de>

Thanks, applied with a space fix.


Takashi

> ---
> --- linux-3.10.25/sound/pci/ctxfi/ctatc.c.orig	2014-01-09 10:12:00.000000000 -0800
> +++ linux-3.10.25/sound/pci/ctxfi/ctatc.c	2014-01-09 10:32:42.000000000 -0800
> @@ -433,10 +433,15 @@ atc_pcm_playback_position(struct ct_atc
>  
>  	if (!src)
>  		return 0;
>  	position = src->ops->get_ca(src);
>  
> +	if(position < apcm->vm_block->addr) {
> +		snd_printdd("ctxfi: bad ca - ca=0x%08x, vba=0x%08x, vbs=0x%08x\n", position, apcm->vm_block->addr, apcm->vm_block->size);
> +		position = apcm->vm_block->addr;
> +	}
> +
>  	size = apcm->vm_block->size;
>  	max_cisz = src->multi * src->rsc.msr;
>  	max_cisz = 128 * (max_cisz < 8 ? max_cisz : 8);
>  
>  	return (position + size - max_cisz - apcm->vm_block->addr) % size;
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>