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

[Alan Horstmann]

On Wednesday 16 July 2008 00:15, you wrote:
> 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...

Thanks for the response on this one.  I'm not sure how to test pause, unless 
xmms uses that for 'PAUSE' button action, when the same effect is seen.

I did try setting various values for silence threshold and size, and when (as 
per the original test) writing 1 period of sine followed by a 2nd writei of 
experimental data, silence values could be found that would eliminate the 
'sustain effect'.  However, when only the single period writei occured I 
could not find any effective values.

Unsurprisingly, my other ice1712 card, ST Audio /Hoontech DSP2000 shows the 
same effect, so if it is a 'hardware feature' it presumably relates to the 
way the envy24 chip operates?

How would I go about experimenting with zeroing the stream just before 
stopping?  Do you mean in _pro_trigger()?

Alan