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