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

[alsa-devel] [1/4] 2.6.23-rc3: known regressions v3
by Michal Piotrowski 25 Aug '07

25 Aug '07

Hi all, Here is a list of some known regressions in 2.6.23-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces Name Regressions fixed since 21-Jun-2007 Adrian Bunk 9 Andi Kleen 5 Linus Torvalds 5 Andrew Morton 4 Al Viro 3 Alan Stern 3 Cornelia Huck 3 Jens Axboe 3 Tejun Heo 3 Unclassified Subject : 2.6.23-rc3-git1 crash/stuck on VIA CN700 system References : http://lkml.org/lkml/2007/8/20/174 Last known good : ? Submitter : Stefan Becker <Stefan.Becker(a)nokia.com> Caused-By : ? Handled-By : ? Status : unknown Subject : 2.6.23-rc2 cross compile regressions (alpha,xtensa) References : http://lkml.org/lkml/2007/8/6/43 Last known good : alpha: 2.6.22-git8 xtensa: 2.6.22-git6 Submitter : Jan Dittmer <jdi(a)l4x.org> Caused-By : ? Handled-By : xtensa: Christian Zankel <chris(a)zankel.net> Status : unknown Subject : console is messed up after resume from s2ram or switching to console from X References : http://lkml.org/lkml/2007/8/4/6 Last known good : ? Submitter : Jeff Chua <jeff.chua.linux(a)gmail.com> Caused-By : ? Handled-By : H. Peter Anvin <hpa(a)zytor.com> Antonino A. Daplas <adaplas(a)gmail.com> Workaround : "s2ram --force --acpi_sleep 1 --vbe_mode" Status : problem is being debugged Subject : konqueror suddenly vanishing, "konqueror: Fatal IO error: client killed" References : http://lkml.org/lkml/2007/7/22/86 Last known good : ? Submitter : Markus <lists4me(a)web.de> Caused-By : ? Handled-By : Ingo Molnar <mingo(a)elte.hu> Status : problem is being debugged ALSA Subject : Master volume control broken References : http://lkml.org/lkml/2007/8/18/46 Last known good : ? Submitter : Thomas Meyer <thomas(a)m3y3r.de> Caused-By : Ivan N. Zlatev <contact(a)i-nz.net> commit 5d5d3bc3eddf2ad97b2cb090b92580e7fed6cee1 Handled-By : ? Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/

3 2

[alsa-devel] Audio quality issue - regular clicks are observed
by Pharaoh . 24 Aug '07

24 Aug '07

Hi While testing the audio driver using aplay in blocking mode, a periodic murmur is observed, this increases with the audio volume and occurs even when there are no issues like xrun etc. Aplay was used in normal read/write mode i.e. no mmap. The song can be heard properly i.e. with no noticable gaps aur hisses but the clicks are audible. I have tried various combinations of period size and buffer size but the quality doesn't seem to improve. I checked the latency between to consecutive calls of snd_pcm_write in aplay and log is as follows. I am having 16 periods of 1K size and from log it is seen that the latency is too much at the buffer boundary, i.e. higlighted and starred line in the logs. I think the clicks are caused due these huge delays since the clicks are also quite periodic. Any thoughts? #aplay -Dhw:0,0 --rate=44100 --format=S16 --channels=2 --period-size=1024 --buffer-size=16384 Learning.wav 1 2 Latency = 0.000000 3 Latency = 0.001805 4 Latency = 0.000741 5 Latency = 0.000674 6 Latency = 0.000643 7 Latency = 0.000668 8 Latency = 0.000625 9 Latency = 0.000611 10 Latency = 0.000647 11 Latency = 0.000627 12 Latency = 0.000626 13 Latency = 0.000635 14 Latency = 0.000631 15 Latency = 0.000616 16 Latency = 0.000645 17 Latency = 0.000634 18 Latency = 0.000958 19 Avg Latency is => 0.000737 20 21 Latency = 0.371909 /********Too much latency***********/ 22 Latency = 0.000767 23 Latency = 0.000701 24 Latency = 0.000696 25 Latency = 0.000657 26 Latency = 0.000677 27 Latency = 0.000667 28 Latency = 0.000673 29 Latency = 0.000674 30 Latency = 0.000627 31 Latency = 0.000675 32 Latency = 0.000880 33 Latency = 0.000726 34 Latency = 0.000682 35 Latency = 0.000705 Latency = 0.000648 37 Avg Latency is => 0.023898 38 39 Latency = 0.361167 /********Too much latency***********/ 40 Latency = 0.000744 41 Latency = 0.000692 42 Latency = 0.000678 43 Latency = 0.000672 44 Latency = 0.000637 45 Latency = 0.000696 46 Latency = 0.000668 47 Latency = 0.000674 48 Latency = 0.000885 49 Latency = 0.000710 50 Latency = 0.000670 51 Latency = 0.000663 52 Latency = 0.000654 53 Latency = 0.000667 54 Latency = 0.000676 55 Avg Latency is => 0.023222 56 57 Latency = 0.361260 /********Too much latency***********/ 58 Latency = 0.000710 59 Latency = 0.000703 60 Latency = 0.000685 61 Latency = 0.000671 62 Latency = 0.000665 63 Latency = 0.000796 64 Latency = 0.000714 65 Latency = 0.000692 66 Latency = 0.000704 67 Latency = 0.000695 -Pharaoh

2 4

[alsa-devel] please test the beta CMI8788 driver
by Clemens Ladisch 24 Aug '07

24 Aug '07

If you have a card based on the C-Media CMI8788 chip (Asound A-8788, Asus Xonar D2, Auzentech X-Meridian, Bgears b-Enspirer, Club3D Theatron DTS, HTOmega Claro, Razer Barracuda AC-1, or Sondigo Inferno), please help testing the new snd-cmi8788 driver. To test it, get the source from the Hg repository, or download this beta package: http://www.informatik.uni-halle.de/~ladischc/alsa-driver-1.0.14-cl1.tar.bz2 To compile, run "./configure", then "make", then, as root, "make install-modules". (If you don't want to compile all the other drivers, use "./configure --with-cards=cmi8788" instead.) What should work: * analog playback (2/4/6/8 channels) and capture * digital playback/capture (device name "plughw:CMI8788,1") * all sample rates (32-192 kHz) Not yet implemented: * front panel playback/capture * capture source selection * SPDIF controls (for AC-3, copyright bit etc.) * MIDI Known bugs: * PCM volume on Asus Xonar doesn't work Unknown bugs: * That's for you to find out! I'm not sure about the channel order. Please try speaker-test -D hw:CMI8788,0 -c 8 -t wav and report if it works correctly. *WARNING*: I don't have the hardware; I cannot run this driver myself. It's quite possible that it crashes your computer or that it causes the speakers to fall onto your cat. ;-) Clemens

1 0

[alsa-devel] Unknown card info
by Jorge Peixoto de Morais Neto 24 Aug '07

24 Aug '07

When I execute sudo modprobe snd_bt87x, I can't capture audio from my tv capture card (mencoder segfaults). It only works when I execute sudo modprobe snd_bt87x load_all=1. Then it seems to work ok. When I issue sudo modprobe snd_bt87x load_all=1, the following lines appear in dmesg: unknown card 0x878-0x1554:0x4011, using default rate 32000 please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> I am obeying the request and mailing this information to you. I have no idea what is the correct digital_rate option; all I know is that the default seems to work ok. I have a cable connecting the sound output of the tv card to the line in of my sound card; it seems that when wathing tv through mplayer this is the mechanism used (and it works ok). However, when recording tv through mencoder, it seems to use snd_bt87x (in fact, it does not work if snd_bt87x is not loaded), and it also works ok. The card option I pass when loading the module bttv is card=139. According to /usr/src/linux/Documentation/video4linux/CARDLIST.bttv, this corresponds to the card Prolink PixelView PlayTV MPEG2 PV-M4900 In fact, there is a sticker in the PCB that reads (if my eyes are not failing me) PixelView PV-M4900 FM.RC The full output of dmesg is attached to this email. If you need any additional information please contact me directly, since I will now unsubscribe to this list. Some possibly useful information: jorge@jorge ~ $ uname -a Linux jorge 2.6.22-gentoo-r3 #1 PREEMPT Tue Aug 14 18:51:06 BRT 2007 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux jorge@jorge ~ $ cat /etc/modprobe.d/tv options bttv card=139 automute=0 options snd_bt87x load_all=1 jorge@jorge ~ $ arecord -l **** List of CAPTURE Hardware Devices **** card 0: CMI8738MC6 [C-Media PCI CMI8738-MC6], device 0: CMI8738-MC6 [C-Media PCI DAC/ADC] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: CMI8738MC6 [C-Media PCI CMI8738-MC6], device 2: CMI8738-MC6 [C-Media PCI IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Bt878 [Brooktree Bt878], device 0: Bt87x Digital [Bt87x Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Bt878 [Brooktree Bt878], device 1: Bt87x Analog [Bt87x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 jorge@jorge ~ $ sudo lspci Password: 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge 00:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 00:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 00:0c.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) -- Software is like sex: it is better when it is free. --Linus Torvalds

3 3

[alsa-devel] Unable to open plughw:0,0 from user program.
by stan 24 Aug '07

24 Aug '07

Hi, I am unable to use plughw:0,0 as a device string while calling err = snd_pcm_open (&alsa_dev, hw_from_default, SND_PCM_STREAM_PLAYBACK, 0); The same call works with hw_from_default == 'default', but fails when it is 'plughw:0,0'. The error is cannot open audio device "plughw:0,0" (Device or resource busy) I am using the latest snapshot of alsa-lib, alsa-lib20070821. I tried debugging but I cannot trace through the macros. As near as I can tell there have been no changes to alsa.conf, and this worked just fine before the latest upgrade alsa package alsa-lib.1.0.14-3 Is this a deliberate change in alsa that is known about, and is there a way to still get the functionality? Thanks.

3 7

[alsa-devel] hw_params function and OSS emulation
by Timur Tabi 24 Aug '07

24 Aug '07

I'm working on an ASoC driver, and I noticed that with OSS emulation enabled, my snd_pcm_ops.hw_params and and snd_pcm_ops.hw_free are called multiple times when an OSS driver uses the OSS emulation. In my case, .hw_params is called *four* times, each time with a different DMA buffer size and number of periods. The problem is that my driver allocates a DMA buffer in my .hw_params function. For now, I have it deallocate the buffers at the top of the function and then allocate new ones based on the new hw_params values. This is really annoying. So I have a few questions: 1) Is there any way this can be fixed? Can't the OSS emulation code figure out what it needs and wait until it's done before it calls .hw_params? As a solution to the DMA buffer deallocate/reallocate hack I'm using, would it be okay to move the actual allocations to snd_pcm_ops.prepare()? My .hw_params function will collect the relevant data and keep them in some private structure. Then when .prepare() is called, I do the actual buffer allocation. 2) Can I assume that .prepare() is called only once? 3) Can I assume that .hw_params() is never called after .prepare() is called? -- Timur Tabi Linux Kernel Developer @ Freescale

3 20

[alsa-devel] Intel-HDA ALC262 (again)
by Andy 23 Aug '07

23 Aug '07

Alas, I spoke too soon. The headphone jack and internal speakers work as expected, until I adjust the main volume (labeled in alsamixer as 'front') at which point both the internal speakers and headphones play! Unplugging the headphones and reconnecting them makes everything OK again. Any ideas? (patch against 2.6.22 that makes my chip mostly work is attached). I guess that alc262_hippo_automute() needs to be called somewhere it isn't, but I couldn't see where. Thanks again! Andy >Yep, I'm happy to report that does indeed fix it! >Thank-you Takashi! :) >Andy. > At Wed, 25 Jul 2007 16:51:25 +0100 (BST), > Andy wrote: > > > > Hello again Takashi, > > > > I put in some printks, and indeed the function > does > > run and it correctly detects that there are no > > headphones present, but the speakers are not > unmuted. > > > > (the 'mute' variable both times is reported as > being > > 0x80 after it is set with snd_hda_codec_amp_read) > > Ah, it means that this intiailization gets called > before restoring the > mixer elements. Since sony model doesn't have the > mixer element for > the NID 0x14 that is linked with 0x15, 0x14 isn't > restored properly in > the end. > > How about the patch below? It's a bit too ad hoc, > but better than > buggy. > ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

2 3

[alsa-devel] I want to improve Sigma-Tel STAC9227 driver / How to implement support for multiple ADC
by Maxim Levitsky 23 Aug '07

23 Aug '07

Hello, I am a user of Sigma-Tel STAC9227 intel hda based chip. I have studied its documentation, and found that alsa driver doesn't support number of its features. 1) it has "analog loop-back" which means it can mix sound just before it enters ADC0 to output of DAC0 (headphones/front). For me it is the most important feature, since I have a tv card with analog output. 2) it has the ability to "swap" left/right channels, and this can be very useful for LFE/center channel 3) It has a VolumeKnob "widget" , that allows to decrease volume of all DACs _after_ their own volumes were applied, and I think I turn it to "master volume" Those things below aren't supported by windows driver ether, but that doesn't mean we can't support that :-) 4) this chip has 3 ADC, each capable recording from different source, but alsa uses only first. 5) I have 5.1 configuration, so DAC1 is unused. It is possible to connect it to "front" mic, and get 7.1 sound card I think about a option "Use front mic as output", for 3Stack configuration 1,2,3 are easy to implement, since those are just mixer switches. But I have a question about 4: Now the driver has buggy support for second ADC, it record from it, but fails to connect it to any input source, and unmute it. I can fix that and trivially add support for third ADC, but current driver makes all ADCs a sub-streams of a single PCM device. I think that sub-streams are meant to be used only by playback PCMs that have hardware support of mixing, so I feel that is is better to make each ADC to be a separate PCM device, with separate mixer controls (enabled/input source/gain), and I want to ask you whenever you agree with me. Also I noticed that dsnoop chokes on record streams with more that one substream, it fails with error, when I try to open second arecord. Best regards, Maxim Levitsky

2 4

Re: [alsa-devel] [Alsa-user] Impossible to make subwoofer work on a Dell XPS M1710w
by Michael Gerdau 23 Aug '07

23 Aug '07

[crossposting to alsa-devel as adviced in ALSA-Configuration.txt] > The model option is _the_ important option for HD-audio driver. > It overrides the configuration preset. As default, the driver reads > the PCI (subsystem) IDs to identify which configuration preset to > use. If not found, the driver does a guess work from the BIOS setup > in most cases. > > Now, since many laptops are shipped with broken BIOS and the guess > work is imperfect, you often face the famous problem -- "sound > doesn't work" (great words that explain everything). Then you can > pass model option for the preset designed for anohter hardware > (e.g. model=thinkpad) to make the driver probe as if it's such a > hardware. If you are lucky, your device is similar with others, and > the driver works with such a preset. If not, we'd need to hack > another preset for matching with your device. > > The list of available model option is found in > ALSA-Configuration.txt. So it seems the Dell XPS M1710 isn't yet listed among the known models and also does not seem to be detected properly (as of hg20070816). 'lspci -v' gives: ... 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ... 'lspci -nv' gives: ... 00:1b.0 Class 0403: 8086:27d8 (rev 01) Subsystem: 1028:01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ... Anything else I could do to help getting it (fully) supported ? Best, Michael -- Vote against SPAM - see http://www.politik-digital.de/spam/ !tagline Michael Gerdau email: mgerdau(a)tiscali.de GPG-keys available on request or at public keyserver

5 15

[alsa-devel] Tascam US-428 USB Problems
by Michael Bourgeous 23 Aug '07

23 Aug '07

Hello, I hope this reaches the Tascam driver developer... I have a Tascam US-428 which worked great with my Athlon XP, but does not work at all with my new system, an Athlon 64 X2. I've tried using the regular alsa driver, as well as the hwdep audio, and jackd always crashes with a SIGSEGV, with the following message in the kernel log: [ 2538.003798] ALSA /home/nitrogen/src/alsa-driver-1.0.14rc3/usb/usx2y/usbusx2yaudio.c:148: should not be here with counts=42 [ 2538.003806] ALSA /home/nitrogen/src/alsa-driver-1.0.14rc3/usb/usx2y/usbusx2yaudio.c:91: active frame status -70. Most probably some hardware problem. n I did some searching through source code, and found that the frame status of -70 (ECOMM) indicates an OHCI buffer overflow error. As soon as the usx2y driver receives this it bails out of whatever it's doing, and jackd crashes. I've tried changing the usx2y driver to ignore such errors, and while there are audio glitches when such an error occurs, jackd no longer crashes and the audio keeps playing. This leads to question one: Is there any reason to bail out instead of trying to recover from errors? I've tried all the different USB ports on my motherboard, different USB cables, and running through a hub instead of a direct connection. None of these things helped. Though the usx2y message says "Most probably some hardware problem", I think this is something that is software related, as other USB devices have no problems. So here is question two: what kinds of problems, software or hardware, would lead to a buffer overflow error, and can I fix this in the driver code? Thanks, Mike Bourgeous

2 6