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

[alsa-devel] ALSA sound/core/pcm_lib.c:210: Unexpected hw_pointer value [1] (stream = 0, delta: -4096, max jitter = 8192): wrong interrupt acknowledge?
by Pharaoh . 28 Aug '07

28 Aug '07

I am getting this error at the start of song, I get this only once and the song plays quite well except some periodic minute/unnoticable clicks which occur often if period size is less. Is there any chance of this being the culprit i.e. causing clicks? I used to get the same messages after every buffer size previously, but after fixing my pointer callback this happens only once at the beginning. After reading the code I think that, this might not be the reason behind clicks, since this is just xrun debug thing, but this doesn't correspond to xruns directly, does it? I got the above error message even when there were no xruns. How serious is this issue? After referring web I collected that, this might happen because the period is not processed as fast as it should be. -pharaoh.

2 1

[alsa-devel] Noise at end of audio file
by Lopez Cruz, Misael 27 Aug '07

27 Aug '07

Hi, I listen some noise at the end of playback of an audio file, with some debug I noticed that the noise appears in the last two period of the playback. I tried changing the minimum number of period (it was 16 and changed to 32) but the noise appears even before. Any idea what could be wrong? Misael

2 5

[alsa-devel] Very elementary question regarding period size
by Pharaoh . 27 Aug '07

27 Aug '07

I am testing out my alsa driver for various period and buffer sizes, at some configurations it doesn't work so arises this very basic question. Is every sound card/hardware supposed to work at all the period sizes? The way I have written my driver, makes the DMA processing dependent on period size so the answer is obvious in my case, that it might not work for all period sizes. Does it hold true for all the cards? -pharaoh.

2 2

[alsa-devel] acl888 chipset
by paul blakeley 27 Aug '07

27 Aug '07

Can someone tell me who wrote the driver for the alc888 chipset. I am currently encountering problems with capturing data from the line-in. Think there maybe a problem with the driver.

2 1

[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