[alsa-devel] snd_pcm_writei() -last value sustained
gineera at aspect135.co.uk
Wed Jul 16 13:22:07 CEST 2008
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
> 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()?
More information about the Alsa-devel