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

[Takashi Iwai]

At Mon, 7 Jul 2008 14:53:35 +0100,
Alan Horstmann wrote:
> 
> 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?

Well, I'd call it's a hardware "feature".  No other hardwares do like
that.

As a workaround, we'll need to put zero'ed short samples before
actually stopping the stream.

I wonder whether this also occurs to pause operation, too.  In the
case of pause, it's a tougher problem...


Takashi