Re: [PATCH] Fix buffer position for ATI SB4x0

[Mauro Carvalho Chehab <mchehab@infradead.org>]

On Mon, 09 Jun 2008 15:17:41 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Sat, 07 Jun 2008 10:27:54 +0200,
> I wrote:
> > 
> > At Fri, 6 Jun 2008 15:31:45 -0300,
> > Mauro Carvalho Chehab wrote:
> > > 
> > > On Fri, 06 Jun 2008 18:49:28 +0200
> > > Takashi Iwai <tiwai@suse.de> wrote:
> > > 
> > > > At Fri, 6 Jun 2008 11:52:32 -0300,
> > > > Mauro Carvalho Chehab wrote:
> > > > > 
> > > > > On Thu, 29 May 2008 16:20:21 +0200
> > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > 
> > > > > > At Thu, 29 May 2008 11:10:22 -0300,
> > > > > > Mauro Carvalho Chehab wrote:
> > > > > > > 
> > > > > > > ATI SB4x0 doesn't need any fix at position.
> > > > > > 
> > > > > > It's not about the position fixing but whether to use the
> > > > > > position-buffer.  The devices on the blacklist are the ones that have
> > > > > > no position buffer.  So, it would fall into LPIB mode, and this list
> > > > > > avoids it from the beginning.
> > > > > > 
> > > > > > > This patch solves the issue of receiving several clicks during capture on those
> > > > > > > devices.
> > > > > > > 
> > > > > > > Tested with a Gateway Notebook MX-6453.
> > > > > > 
> > > > > > The click noise is often a different problem.  Did you already try
> > > > > > the patch below?
> > > > > 
> > > > > The click seems associated to some residual samples inside the buffer. Here it
> > > > > is a sample of the king of click noise I'm hearing here (captured from CD input entry):
> > > > > 	http://linuxtv.org/~mchehab/snd.ogg
> > > > 
> > > > (I didn't check the ogg file yet, and just a wild guess)
> > > > 
> > > > Is it with dsnoop plugin?  With "default" PCM, ALSA uses dsnoop for
> > > > capture to allow multiplexing for HD-audio.  Does it happen with "hw"
> > > > or "plughw" PCM?
> > > 
> > > Results with the cdplay:
> > > 
> > > With "default" PCM (both with and without mmap):
> > > 	several clicks per second, very high clicks;
> > > 	(like a very risky analog disk)
> > 
> > Hm, it's obviously a problem.  I couldn't reproduce it on my machine
> > with HD-audio, so it might be controller/codec-specific, though.
> > 
> > > With "hw" or "plughw" (no mmap):
> > > 	less clicks (something like two clicks or three per second), with less volume.
> > > 	both hw and plughw produces the same effect.
> > 
> > If it works with hw, plughw should have no effect (i.e. no conversion
> > is done).  Thus it's logical that both hw and plughw have the same
> > result.
> > 
> > > With "hw" or "plughw" and mmap (-M):
> > > 	high quality. no noticeable clicks.
> > > 
> > > So, it seems that there are two different issues: one with dsnoop and another
> > > with non-mmapped captures.
> > 
> > Interesting.  The fact that even "hw" without mmap causes occasional
> > click noises implies that there is certainly a problem with the DMA
> > position calculation.  The dsnoop has more problems likely because it
> > uses smaller period size and more periods than hw, I guess.
> > Still not sure why the mmap mode works.
> > 
> > Anyway, it means that the capture position is wrongly reported, maybe
> > just in a reverse way of the playback position -- a few samples ahead
> > than the real position.  Sigh, another workaround is needed.
> 
> The patch below adds another workaround for the DMA buffer position.
> Could you give it a try?  It adds as default one sample delay for
> issuing the interrupt so that the DMA pointer gets the right
> position.  The delay can be changed (even dynamically) via bdl_pos_adj
> module option.

I tried it here, but I didn't noticed any results. I've ranged the value from 1
to 317 (I had to stop/start record each time). I tried with the default PCM input,
since this way is easier to notice the click.

Cheers,
Mauro