April 2008 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Buffering issues 2
by Lennart Poettering 16 May '08

16 May '08

Heya! In addition to the buffering issues pointed out on http://mailman.alsa-project.org/pipermail/alsa-devel/2008-April/007354.html I now have some more issues with the way buffering works in ALSA. This time I am pretty sure it's a bug in the HDA drivers. PulseAudio basically does this (again, as part of the glitch-free playback model, see http://0pointer.de/blog/projects/pulse-glitch-free.html): for (;;) { for (;;) { snd_pcm_hwsync(); n = snd_pcm_avail_update(); if (!n) break; fill_up(n); } usleep(buffer_time - 20ms); } The buffer time is 370ms, so we usually sleep for 350ms. It's a lot more complex actually, due to deviating timing and some code that we don't enter a busy loop if the CPU is slower then the sound card and so on and so on. However, basically it's this algorithm. This works fine on USB. However on HDA it sometimes happens that snd_pcm_avail_update() is not properly updated at the right time. Instead it seems to return what was current one iteration earlier. I.e. we fill up the hw buffer until _avail_update() returns 0. Then assuming that it is fully filled up we go to sleep for 350ms. When we wake up we query _avail_update() again and it will immediately return 0. We thus don't write anything to the device. Instead we go to sleep for another 350ms. Of course, when we wake up again the buffer will already have underrun (since 700 ms passed since the last write to the buffer and th buffer is only 370ms long) and we have a problem. In short: _avail_update() told us that everything was alright and we trusted it and it lied to us. The happens to be configured to 2 periods. So even if _avail_update() has some kind of period granularity (?) it should always have told us after we come back from the sleeping that at least *one* period is free. But it said 0 frames. Nada. Rien. Nichts. Kaputt. I *am* calling snd_pcm_hwsync(). So I'd assume that _avail_update() would be as up to date as it gets. But it isn't. :-( This happens regardless if I open the device as "front:0" (i.e. with softvol in line) or as "hw:0" (no plugins). This doesn't always happen. It seems to depend on the machine how often this happens. On one machine I can reliably reproduce this after 30 iterations. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

3 5

[alsa-devel] Acer Aspire 8920g / snd-hda-intel / ALC889
by Andy Green 13 May '08

13 May '08

Hi folks - I have a new 8920g on Fedora development running 2.6.25 which has $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.16rc2 (Thu Jan 31 16:40:16 2008 UTC). I get a decent looking set of alsa things in /proc/asound $ cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfc300000 irq 22 and dmesg says that model=acer was selected reasonably enough. I can play audio down the logical sound devices, including cat /dev/urandom > /dev/dsp and the interrupt count goes up in /proc/interrupts. Alsamixer shows a bunch of things and I twiddled them all to no avail. There has never been even a click from the speakers or headphone jack on this machine. At least three funnies on this machine: 1) It is confused if it has ALC889 or ALC883 in there $ grep ALC /proc/asound/* -R /proc/asound/card0/codec#0:Codec: Realtek ALC889 <==== 889 /proc/asound/card0/pcm2c/sub0/info:id: ALC883 Analog <=== 883... /proc/asound/card0/pcm2c/sub0/info:name: ALC883 Analog /proc/asound/card0/pcm2c/info:id: ALC883 Analog /proc/asound/card0/pcm2c/info:name: ALC883 Analog /proc/asound/card0/pcm0c/sub0/info:id: ALC883 Analog /proc/asound/card0/pcm0c/sub0/info:name: ALC883 Analog /proc/asound/card0/pcm0c/info:id: ALC883 Analog /proc/asound/card0/pcm0c/info:name: ALC883 Analog /proc/asound/card0/pcm0p/sub0/info:id: ALC883 Analog /proc/asound/card0/pcm0p/sub0/info:name: ALC883 Analog /proc/asound/card0/pcm0p/info:id: ALC883 Analog /proc/asound/card0/pcm0p/info:name: ALC883 Analog /proc/asound/Intel/codec#0:Codec: Realtek ALC889 <=== 889 /proc/asound/Intel/pcm2c/sub0/info:id: ALC883 Analog /proc/asound/Intel/pcm2c/sub0/info:name: ALC883 Analog /proc/asound/Intel/pcm2c/info:id: ALC883 Analog /proc/asound/Intel/pcm2c/info:name: ALC883 Analog /proc/asound/Intel/pcm0c/sub0/info:id: ALC883 Analog /proc/asound/Intel/pcm0c/sub0/info:name: ALC883 Analog /proc/asound/Intel/pcm0c/info:id: ALC883 Analog /proc/asound/Intel/pcm0c/info:name: ALC883 Analog /proc/asound/Intel/pcm0p/sub0/info:id: ALC883 Analog /proc/asound/Intel/pcm0p/sub0/info:name: ALC883 Analog /proc/asound/Intel/pcm0p/info:id: ALC883 Analog /proc/asound/Intel/pcm0p/info:name: ALC883 Analog /proc/asound/oss/sndstat:0: ALC883 Analog (DUPLEX) /proc/asound/oss/sndstat:0: Realtek ALC889 /proc/asound/pcm:00-02: ALC883 Analog : ALC883 Analog : capture 1 /proc/asound/pcm:00-00: ALC883 Analog : ALC883 Analog : playback 1 : capture 1 2) from dmesg ALSA sound/pci/hda/hda_intel.c:1810: chipset global capabilities = 0x4401 ALSA sound/pci/hda/hda_intel.c:749: codec_mask = 0x3 ALSA sound/pci/hda/hda_codec.c:2211: hda_codec: model 'acer' is selected ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Headphone Playback Volume, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Speaker Playback Volume, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Mono Playback Volume, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Line-Out Playback Volume, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Speaker Playback Switch, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Mono Playback Switch, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave IEC958 Playback Switch, skipped 3) there is a funny embedded capacitive volume control thing on this device, whether it gates output by itself or is just a bunch of special keyboard keys, I dunno. Any ideas, more information needed? -Andy

2 14

[alsa-devel] Pulseaudio alsa configure hook
by Sjoerd Simons 13 May '08

13 May '08

Hi, The attached patch extends the alsa pulse plugin set with a alsa configuration hook. Allowing one to specify some configuration parameters that only come into effect when pulseaudio is running. For example a configution file like: @hooks [ { func on_pulse_is_running pcm.!default { type pulse } ctl.!default { type pulse } } ] will redirect the default alsa pcm and ctl to pulse iff pulse is running. (Assuming you defined the hook function correctly ofcourse) This is usefull for distributions that don't want to force their users to switch completely to pulseaudio, but have things a bit more dynamic :) The solutions isn't optimal though. It will mean that every program loading accessing alsa will try to make an (extra) connection to pulse to decide what to do. But i think it's the best we can do for now (or at least that i can do with my minimal knowledge of alsa). A nicer solution would be a way to always specify the pulse plugin as default and have a sort of fallback for when that fails. Comments on the patch appreciated :) Sjoerd PS: I'm not on alsa-devel, so please keep me in the CC -- GREAT MOMENTS IN HISTORY (#7): April 2, 1751 Issac Newton becomes discouraged when he falls up a flight of stairs.

2 3

[alsa-devel] My issues with the ALSA API
by Lennart Poettering 09 May '08

09 May '08

Heya! A while back I compiled a list of issues I found with the ALSA API while I was hacking PulseAudio. I kept it up to date ever since. It has the title "Why I hate ALSA", but this is merely a catchy title, I am not trying to offend anyone, nor do I think that the ALSA API is particularly bad. Back at FOMS in January this year, I showed this list to James. He acknowledged most of those issues. But I am sure that the other ALSA devs might be interested too: http://pulseaudio.org/wiki/WhyIHateALSA Comments welcome! Thank you, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

4 9

[alsa-devel] Patch - ESI Maya44 driver
by Rainer Zimmermann 09 May '08

09 May '08

Hi Takashi, here's the maya44 patch. This is a patch against the current alsa-kernel tree. I did add 2 definitions to ice1712.h (snd_ice1724_get_route_val and snd_ice1724_put_route_val), which allowed me to move some of the maya44 specific code to maya44.c . There are still a few maya44 special cases in ice1724.c, because maya44 uses the "con" channel and routing switches differently. This is not really clean style I think, but I would suggest sorting this out later, as it would again require larger changes to ice1724.c and testing with other hardware. Hope everything is ok with you, for now. This patch does *not* limit the sampling rate to 96kHz for capture, as discussed before. best regards, -Rainer -- Lightshed IT Services Löfflerstr. 27, 22765 Hamburg, Germany * mail(a)lightshed.de * www.lightshed.de

3 6

[alsa-devel] SoC sound support for imx27
by Juergen Beisert 08 May '08

08 May '08

Hi, I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S. I found the imx21 already in the repository (may it will help for my job). Is anybody else working on i.MX27 support (to avoid to reinvention everything)? Regards Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9

5 16

[alsa-devel] [RFC] virtual master control for HD-audio
by Takashi Iwai 06 May '08

06 May '08

Hi, another thing I'd like to push into the next kernel is the virtual master volume control. As I posted in earlier posts, it adds virtual controls that have several slave controls with the same types, e.g. Front, Surround, Center, LFE, etc. Then these are adjusted simultaneously via the master control. It'd be appreciated if some one can test the patches with HD-audio h/w that has no master control yet (e.g. some STAC codecs). Note that this won't add the master volumes if there are no real volume controls. Some codecs have really no volume control, and this won't help for such devices. Two (and one for driver) patches will follow after this. Takashi

5 27

Re: [alsa-devel] [Alsa-user] Jetway j7f2 via82xx volume problem: sound suddenly stops when increasing volume: "SOLVED" (well ... sort of)
by Zoilo Gomez 03 May '08

03 May '08

(Sorry for cross-posting from alsa-user; however, on 2nd thought I think this really belongs in alsa-devel): === I think I have found what is causing this problem: in ac97_patch.c / int patch_vt1617a(...) there is a line of code: >>> snd_ac97_write_cache(a97, 0x5c, 0x20); According to a comment, this code is supposed to "bring the analog power consumption to normal, like WinXP driver for EPIA SP". If I comment out this line, the problem appears to be solved ... I can now put all volume controls to maximum values and the sound will keep playing. This is consistent with the apparent introduction of this bug in kernel 2.6.19 (includes alsa-driver version 1.0.12rc1): no such problem occurred until 2.6.18, but all kernels since 2.6.19 do suffer from this problem. The line of code above first shows up in linux-2.6.19. Unfortunately, since I do not have a datasheet for the VT1617A chip set, I cannot verify the exact semantics, or suggest an improvement. Can anyone with a datasheet please suggest a proper patch to this line of code? TIA, Z. ====== Zoilo Gomez wrote: > In the mean time I have found that kernels 2.6.15 and 2.6.16 do not > suffer from this problem, whereas 2.6.22 till 2.6.25 do. > > Testing for kernels 2.6.17 till 2.6.21 is somewhat complicated in my > setup, because there are other problems (NFS-related) which I need to > sort out. > > So it looks like there is a bug somehow. > > Providing the dxs_support parameter does not make any difference, no > matter what value I set it to. > > Z. > > > Zoilo Gomez wrote: >> I have several J7F2 boards from Jetway, containing a 8237 via sound >> device on the south bridge. >> >> Using the alsa-driver, when I increase the volume then at some point >> all over sudden the sound stops. On some boards this happens at 75%, >> on others already at 60%, or 90%. Bringing the volume down again does >> not bring the audio back ... >> >> I am using the alsa-drivers with MPlayer. >> >> Although to me this smells like a hardware problem, I understand from >> googling around that this can be fixed with software, but I cannot >> find the correct solution anywhere. I have tested with gentoo kernels >> 2.6.22 and 2.6.24. >> >> AFAIK there are only 2 ways to get the sound back once it has stopped: >> >> 1) reset the mobo >> 2) rmmod snd-via82xx, followed by modprobe snd-via82xx >> >> The strange thing is that in option 2), the problem seems to be gone >> once the driver has been reloaded; from that moment on it is working >> fine ....! >> >> There is a driver from Via Arena (viaudiocombo) that seems to work >> fine, but it is OSS i.o. ALSA, and also a development by Via Arena >> i.o. the Linux community. Besides, I need synchronization features >> from the audio driver, and I do not think that OSS support this (not >> 100% sure). >> >> >> Can anyone help me and shed light on this? >> >> >> TIA! >> >> Zoilo. >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save >> $100. Use priority code J8TL2D2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java… >> >> _______________________________________________ >> Alsa-user mailing list >> Alsa-user(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/alsa-user >> >> >> > > >

2 9

[alsa-devel] Another unknown bt878
by John R. 02 May '08

02 May '08

Sound doesn't work on my bt878 based card. Let me know what other information is needed... kernel 2.6.24.2: Apr 14 20:28:38 server kernel: unknown card 0x878-0xaa00:0x1460 Apr 14 20:28:38 server kernel: please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> Apr 14 20:28:38 server kernel: ACPI: PCI Interrupt 0000:05:00.1[A] -> GSI 18 (level, low) -> IRQ 18 Apr 14 20:28:38 server kernel: bt87x0: Using board 0, analog, digital (rate 32000 Hz) Apr 14 20:28:38 server kernel: unknown card 0x878-0xaa01:0x1461 Apr 14 20:28:38 server kernel: please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> Apr 14 20:28:38 server kernel: ACPI: PCI Interrupt 0000:05:01.1[A] -> GSI 19 (level, low) -> IRQ 19 Apr 14 20:28:38 server kernel: bt87x1: Using board 0, analog, digital (rate 32000 Hz) Apr 14 20:28:38 server kernel: unknown card 0x878-0xaa02:0x1462 Apr 14 20:28:38 server kernel: please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> Apr 14 20:28:38 server kernel: ACPI: PCI Interrupt 0000:05:02.1[A] -> GSI 16 (level, low) -> IRQ 16 Apr 14 20:28:38 server kernel: bt87x2: Using board 0, analog, digital (rate 3200 0 Hz) Apr 14 20:28:38 server kernel: unknown card 0x878-0xaa03:0x1463 Apr 14 20:28:38 server kernel: please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> Apr 14 20:28:38 server kernel: ACPI: PCI Interrupt 0000:05:03.1[A] -> GSI 17 (level, low) -> IRQ 17 Apr 14 20:28:38 server kernel: bt87x3: Using board 0, analog, digital (rate 32000 Hz) lspci: 05:00.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 05:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 05:01.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 05:01.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 05:02.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 05:02.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 05:03.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 05:03.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) at boot: bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 18 (level, low) -> IRQ 18 bttv0: Bt878 (rev 17) at 0000:05:00.0, irq: 18, latency: 64, mmio: 0xdfcfe000 bttv0: detected: Provideo PV150A-1 [card=98], PCI subsystem ID is aa00:1460 bttv0: using: ProVideo PV150 [card=98,autodetected] bttv0: gpio: en=00000000, out=00000000 in=00ffffff [init] bttv0: tuner absent bttv0: registered device video0 bttv0: registered device vbi0 bttv0: PLL: 28636363 => 35468950 .. ok bttv: Bt8xx card found (1). ACPI: PCI Interrupt 0000:05:01.0[A] -> GSI 19 (level, low) -> IRQ 19 bttv1: Bt878 (rev 17) at 0000:05:01.0, irq: 19, latency: 64, mmio: 0xdfcfc000 bttv1: detected: Provideo PV150A-2 [card=98], PCI subsystem ID is aa01:1461 bttv1: using: ProVideo PV150 [card=98,autodetected] bttv1: gpio: en=00000000, out=00000000 in=00ffffff [init] bttv1: tuner absent bttv1: registered device video1 bttv1: registered device vbi1 bttv1: PLL: 28636363 => 35468950 .. ok bttv: Bt8xx card found (2). ACPI: PCI Interrupt 0000:05:02.0[A] -> GSI 16 (level, low) -> IRQ 16 bttv2: Bt878 (rev 17) at 0000:05:02.0, irq: 16, latency: 64, mmio: 0xdfcfa000 bttv2: detected: Provideo PV150A-3 [card=98], PCI subsystem ID is aa02:1462 bttv2: using: ProVideo PV150 [card=98,autodetected] bttv2: gpio: en=00000000, out=00000000 in=00ffffff [init] bttv2: tuner absent bttv2: registered device video2 bttv2: registered device vbi2 bttv2: PLL: 28636363 => 35468950 .. ok bttv: Bt8xx card found (3). ACPI: PCI Interrupt 0000:05:03.0[A] -> GSI 17 (level, low) -> IRQ 17 bttv3: Bt878 (rev 17) at 0000:05:03.0, irq: 17, latency: 64, mmio: 0xdfcf8000 bttv3: detected: Provideo PV150A-4 [card=98], PCI subsystem ID is aa03:1463 bttv3: using: ProVideo PV150 [card=98,autodetected] bttv3: gpio: en=00000000, out=00000000 in=00ffffff [init] bttv3: tuner absent bttv3: registered device video3 bttv3: registered device vbi3 bttv3: PLL: 28636363 => 35468950 .. ok

2 2

[alsa-devel] help with idt 92hd206 codec for intel hda?
by Greg Zornetzer 02 May '08

02 May '08

Hi all, I recently acquired an ECS GF7100PVT-M3 motherboard, which appears to use the IDT 92HD206 codec for HDA. Unfortunately, it doesn't appear to have full support under ALSA. It gets detected as another Sigmatel chip. Analog stereo output appears to work, but the mixer doesn't find any of the normal inputs. I found the tech specs for the chip at http://www.idt.com/products/getDoc.cfm?docID=13461840 I've attached an lspci output and the codec file to this email. I'm not much of an driver hacker, but if someone could give me an idea of what needs to go into the patch_sigmatel.c file to make this thing work, I'd be willing to try. I'm also more than willing to test out patches on my setup. Thanks in advance for your help. -Greg

4 11