[alsa-devel] snd_pcm_writei() -last value sustained
tiwai at suse.de
Wed Jul 16 01:15:17 CEST 2008
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
> 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...
More information about the Alsa-devel