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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
