Bug#462753: libao2: need to clear the final period in alsa driver before closing it.
xiphmont at gmail.com
Fri Jan 29 10:02:47 UTC 2010
> 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)
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 126.96.36.199 #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
> - SourceForge.net: SoX - Sound eXchange: 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).
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?
More information about the pkg-xiph-maint