[alsa-devel] snd_pcm_writei() -last value sustained
gineera at aspect135.co.uk
Thu Jul 17 15:56:50 CEST 2008
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,
> > > 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!).
More information about the Alsa-devel