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