[alsa-devel] snd_pcm_writei() -last value sustained

[Alan Horstmann]

On Friday 04 July 2008 09:38, I wrote:
> Working on an app I am seeing several strange effects, and this is one of
> them.
>
> It can be demonstrated with the pcm.c example program, and I have attempted
> to attach a small shot of Audacity capturing the effect.
>
> After writing to the pcm with snd_pcm_writei() a certain amount of data (I
> have pcm.c doing 2 periods) the value captured from the soundcard remains
> at the last value thereafter; clearly this card doesn't have DC elimination
> or this would not be seen.
>
> The sound card is ice1712 (DMX6fire); I had always noticed the PCM meters
> in envy24control often stayed high if something like XMMS was stopped or
> paused during play, but thought it a metering fault.  Now it appears to be
> actual pcm value that 'gets stuck'.
>
> Close examination with Audacity shows it is in fact the last-but-one value
> that is sustained.
>
> Is this expected behaviour, configuration fault, driver bug or other
> problem? I had expected that after the block of data had been written out
> as audio the signal would return to zero straightaway.  Can anyone give me
> any clues?

This seems to be an issue with the ice1712 driver: it does not occur with 
au8820 device at all.
Note that all the results reported here are using pcm.c, not any other app 
code at all, and correspond to effects seen in normal usage over the past 
couple of years.

I have very littlle idea about the inner workings of alsa drivers, but notice 
that in
	snd_ice1712_pro_trigger()
the effect of SNDRV_PCM_TRIGGER_STOP is to set the envy24 chip play bit off, 
which I would expect to essentially freeze the cards playback operation.  
Could that be why?

My tests have involved adding to pcm.c (write method) firstly to limit the 
number of periods played, set to 1.  Then I re-use the data space, writing 
various waveforms including a ramp, or individual data points, before writei 
another period from the start.  It can be clearly demonstrated that setting 
the last-but one sample for a particular channel sets the output to zero 
long-term.  This does not happen with the last sample.  Otherwise it remains 
forever at the last-but-one sample value.

The attached shot shows existing sine data in the space, except for the 
last-but-one sample being zero, and shows that the output ends up at zero.

Can anyone confirm this looks like a flaw in the driver, or am I using it 
wrongly etc?

Alan

Actually, I've attached the shot to subsequent email in case it would cause 
this email to be blocked.