On Mon, 09 Jun 2008 15:17:41 +0200 Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxx> 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@xxxxxxx> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
