[alsa-devel] snd_pcm_writei() -last value sustained
gineera at aspect135.co.uk
Mon Jul 7 15:53:35 CEST 2008
On Friday 04 July 2008 09:38, I wrote:
> Working on an app I am seeing several strange effects, and this is one of
> 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
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
Actually, I've attached the shot to subsequent email in case it would cause
this email to be blocked.
More information about the Alsa-devel