[alsa-devel] snd_pcm_writei() -last value sustained
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?
Alan
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?
Alan
Actually, I've attached the shot to subsequent email in case it would cause this email to be blocked.
On Monday 07 July 2008 14:53, I wrote:
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.
(snip)
Actually, I've attached the shot to subsequent email in case it would cause this email to be blocked.
Attached here.
Alan
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
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
On Wednesday 16 July 2008 12:22, Alan Horstmann wrote:
On Wednesday 16 July 2008 00:15, you wrote:
At Mon, 7 Jul 2008 14:53:35 +0100,
(snip)
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()?
Further info, I noticed in the envy24 datasheet, (rev 2.2 1.03.00) p 4-24 states (near bottom of page)
'... when DMAs are stopped, the last latched value is retained. This "DC" value ...'
so you were right about 'hardware feature'!
Alan
On Wednesday 16 July 2008 13:01, Alan Horstmann wrote:
On Wednesday 16 July 2008 12:22, Alan Horstmann wrote:
On Wednesday 16 July 2008 00:15, you wrote:
At Mon, 7 Jul 2008 14:53:35 +0100,
(snip)
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()?
Further info, I noticed in the envy24 datasheet, (rev 2.2 1.03.00) p 4-24 states (near bottom of page)
'... when DMAs are stopped, the last latched value is retained. This "DC" value ...'
so you were right about 'hardware feature'!
Perhaps I should mention now another odd effect I am getting on this card. Using the same pcm.c test code, if after writei() 1 period of sine I write, say 1/3 period from a zeroed samples area, what I see is 1 period of sine followed by 1/3 period of zero, then 2/3 period of sine, apparently appearing out of nowhere. (Presumably from the sound buffers somewhere).
This suggests to me that the pcm system, once started, is always transfering a full period, even if there is not a full period of new data. Is this possible or to be expected, or another feature of the hardware? In other cases where I simply writei() less than 1 period of data I see phantom garbage following on to a complete period size.
How can I trace this further, as it is deeper than my present Alsa knowledge (apart from the slow process of learning of course!).
Thanks
Alan
participants (2)
-
Alan Horstmann -
Takashi Iwai