> I have tested reproduce_libao_bug.c today, and the problem is still > reproducible for me. > > Here is the kernel version. > % uname -a > Linux debian 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686 > GNU/Linux > > Here is an output of lspci -vv (whole log is attached as named lspci-vv on > this mail): > 00:11.5 Multimedia audio controller: VIA Technologies, Inc. > VT8233/A/8235/8237 AC97 Audio Controller > (rev 60)
Bingo! You have a known buggy sound card. Actually, it's not clear if the card itself is buggy or only the ALSA driver for it is... regardless, VIA 82xx is known to have all sorts of transfer problems. A click at the end is usually the least of the problems. This card is also prone to xruns and crackles during normal playback, and we also have reports of driver lockups in the kernel :-( Again, I don't know if that's due to the hardware, ALSA driver or both (my bet is both). But this type of VIA audio has been all over the bug trackers for a long time. > Additionally, I also tested on other machine using Knoppix. > On this machine below, reproduce_libao_bug.c works properly. No noises at end > of the playback. > > % uname -a > Linux Microknoppix 2.6.28.4 #8 SMP PREEMPT Mon Feb 9 14:33:28 CET 2009 i686 > GNU/Linux > > And here is an output of lspci -vv (whole log is attached as named > lspci-vv-2nd-machine): > 00:0c.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 04) Yes, this is a very nice sound card family. Not fancy, but very solid. > FYI, the following bug reports might also informative. > - SourceForge.net: SoX - Sound eXchange: Detail: 1720683 - Sox's alsa output > plays extra noise at > end of wav files > http://sourceforge.net/tracker/?func=detail&atid=110706&aid=1720683&group_id=10706 > > - SourceForge.net: SoX - Sound eXchange: sox-devel > > http://sourceforge.net/mailarchive/forum.php?thread_name=47BAB5CB.3070506%40inz.sakura.ne.jp&forum_name=sox-devel Thank you for the extra information. Sigh... sometimes I hate the ALSA developers so much. This sort of thing is exactly what an abstraction layer is supposed to hide. I have spoken to ALSA developers in the past as well, and what they told me about aligned transfers was in direct contradiction. Specifically, I brought this up in the past with Clemens Ladisch (when ALSA still used aligned transfers) and he said that you don't actually have any way of knowing in userspace what the hardware chunk size and current alignment is because partial transfers happen all the time due to timing details, and all the userspace code trying to do this by keeping blocks always the same size is wrong. So, tracking the transfer alignment for VIA 82xx is probably working by accident, or perhaps, only 'working' for this single card. Hm, maybe setting a min_silence workahead would also solve this problem. It would burn some CPU but it might be worth it. Unfortunately, the strategy of 'transferring extra silence at the end' is not enough to fix this card in general (and it breaks some other features in libao; some uses become very unhapppy if you transfer extra data, like gapless batching). However, the one thing that one of the bug reporters in our own bugtracker found was that building libao without MMIO support in alsa mostly fixes the problems with this card (it improves playback, but makes transfers slower, which cause extra xruns... neither way works 100% correctly). See: https://trac.xiph.org/ticket/461 It might make things better enough to add to the alsa driver though. A question-- if the kernel is built with genuine OSS (no OSS emulation in ALSA, actual OSS) does the sound card still have this problem? Monty -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
