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

[alsa-devel] Hda-intel: AC_VERB_SET_PIN_WIDGET_CONTROL appears to do nothing for HDMI device
by Ben Firshman 13 Mar '08

13 Mar '08

This is on 1.0.16. Forgive me if I appear clueless, I have only been working on this for the past few hours. In an attempt to get HDMI audio working on the AppleTV, I have added this line to the presets in patch_atihdmi.c: { .id = 0x10951390, .name = "SI1390 HDMI", .patch = patch_atihdmi }, The device is detected fine: ben@mythfrontend:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: ALC882 Analog [ALC882 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 1: ALC882 Digital [ALC882 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 3: ATI HDMI [ATI HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 ben@mythfrontend:~$ and I can send audio to the device, but it doesn't work. I presume this because this is doing nothing: static struct hda_verb atihdmi_basic_init[] = { /* enable digital output on pin widget */ { 0x03, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT }, {} /* terminator */ }; ben@mythfrontend:~$ cat /proc/asound/card0/codec#1 Codec: Generic 1095 SI1390 HDMI Address: 1 Vendor Id: 0x10951390 Subsystem Id: 0xffffffff Revision Id: 0x100000 No Modem Function Group found Default PCM: rates [0x0]: bits [0x0]: formats [0x0]: Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x6211: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x5]: PCM AC3 Node 0x03 [Pin Complex] wcaps 0x40738d: Stereo Digital Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0894: OUT Detect R/L Pin Default 0x98460010: [Fixed] SPDIF Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Connection: 1 0x02 "Pin-ctls: 0x00:" should be reading "Pin-ctls: 0x40: OUT" should it not? What is wrong? Thanks Ben

2 4

[alsa-devel] aplay doesnt work - new problem`
by Pharaoh . 13 Mar '08

13 Mar '08

I am trying to run my pcm external io type plugin on an arm based board. I have no kernel alsa driver and the user space plugin is supposed to take care of talking to DSP using shared memorty and send sound data. Since, I dont have kernel space ALSA driver, do I need to enable kernel ALSA support in .config? I am facing following problem, #aplay ALSA lib conf.c:2852:(snd_config_hook_load) cannot access file /home/pharaoh/alsa/cards/aliases.conf ALSA lib pcm.c:2014:(snd_pcm_open_conf) Invalid type for PCM default definition (id: default, value: cards.pcm.default) aplay: main:550: audio open error: Invalid argument I can see that, aliases.conf is being searched at wrong place (its actually looking on my host machine), how can I fix this? -pharaoh.

2 4

[alsa-devel] driver development questions
by gmail zaq79324 12 Mar '08

12 Mar '08

Hi everyone, I'm currently developing an ALSA driver from scratch. It is almost done, but memory buffer management problem remains. I have tried in various way of debugging. But currently I'm almost giving it up. My target hardware has a small data buffer(2K+2K ring buffer). The driver fills the first half buffer(2K) and writes hardware port. After this the interrupt occurs to urge writting the second half buffer and hardware port. The second buffer is filled in the same way. The buffer filling scheme will repeat continuously until the end of the sound. Through my driver, aplay command can generate the sound within few seconds, but it stops before finishing completely. It seems to have the problem of buffer management. So I set xrun_debug option like as follows. echo 1 > /proc/asound/SM502I2S/pcm0p/xrun_debug And I got the following output. Does anyone know what the problem is and how to fix it? # ./bin/aplay --channels=1 --period-size=2048 sample.wav Playing WAVE 'sample.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo aplay: pcm_write:1266: write error: Input/output error ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -2048, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -2048, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -2048, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -2048, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? Regards, Tadashi

2 1

[alsa-devel] It's time to discuss how to get a Gadget Labs driver into the Alsa tree...
by Mike Mazarick 12 Mar '08

12 Mar '08

As discussed and posted to the Alsa Devel and Planet CCRMA lists back in December (when this was 'a dream' ), we currently have a working Gadget Labs Alsa driver. There are a few more 'features' that are being considered for development (multi card support, a control panel, etc) and more extensive testing and verification by novice users is desired. The main idea is that we intend to ask the main Alsa developers for information twice; first when we have a functional driver and second when we have one that is 'user tested' and is ready to go (ie. when there is a high degree of certainty that all the features are finished and it's use won't cause any major problems). We are now at the first crossroads. There is a small team of developers, Dave Marion and Rick Macri, with some assistance from Pete Mander on SVN setup (Dave and Rick finished before Pete got a chance to 'play'). We have set up a sourceforge page to centralize our effort. The developers and I believe the code currently in the SVN trunk (gl824) is suitable for identifying the appropriate steps to get it from the project SVN repository into the Alsa Hg tree. The project main page is here: https://sourceforge.net/projects/wavepro-driver/ The source code is in an SVN repository here: http://wavepro-driver.svn.sourceforge.net/viewvc/wavepro-driver/ There is a very short web page listed for development: http://wavepro-driver.sourceforge.net/ There is a private mailing list of about 16 people that is tracking what is going on. The group email address is: wavepro-driver-developers(a)lists.sourceforge.net (however, you may have to be subscribed to mail something to the list; I'm not sure). If you are subscribed, there is an archive available here: https://sourceforge.net/mailarchive/forum.php?forum_name=wavepro-driver-deve lopers Our goal is to have this driver included in Alsa so that an end user could have this type of card in their system, and everything would automagically work like all other cards. The only way this can happen is if the driver was included as part of Alsa. The key 'next' questions are: 1. When are the next couple of releases of Alsa planned? How much time before the release date should all drivers be 'in the Hg tree'? 2. Does the code that is currently in the Gadget Labs SVN repository meet the coding and syntax standards of Alsa? We've tried to make it meet the standards, and it is fairly easy to change at this stage if you happen to spot something that is inconsistent with what you'd recommend. 3. We have not modified Alsa to make this driver automatically; there is a 'Makefile' included currently. We currently 'modprobe snd_rawmidi' and 'modproble snd_pcm' and then 'insmod gl824.ko' to get it installed. The required changes to Alsa are fairly trivial and would be the same for every other sound card. Please let us know if there is something that should happen besides what is in the GL repository. 4. One of the key reasons that this driver was able to be developed and tested in 2-3 months of part time effort is because there is already complete source available for a Windows driver, complete with new firmware and vhdl source (see 'External' in the repository). The Windows developer is a member of our mailing list and has been encouraging/helping our effort. However, he didn't bother with GPL licensing (it's a 'Mostek/Waldemar' license instead, but the source is readily available). There may be a few header files that he wrote and the PLD firmware is definitely from his development. Will everything (including the firmware) need to be GPLv2 before it can be included in the alsa tree? 5. What is needed for support? What would you like us to be available to do going forward? 6. How can we make your life a little easier by modifying our software? What would you like to see that you don't see? Although we will diligently try to get a broader base of testing to happen, we will tell you realistically that there are probably very few users who are likely to test this out. I don't know of the exact number of Gadget Labs cards that were produced, but the best guess is ~5,000 cards before the manufacturer went bankrupt in 2001. We feel the effort of creating a linux driver has been advertised in most of the appropriate places, but the mailing list that is tracking this is only 16 people, with 4 main participants. In other words, I don't think this will be a 'SoundBlaster' or 'Audigy' with thousands of people giving feedback on how it works. However, I do believe that this will be a very viable and cost effective solution for some people who want an 8 channel in/out, 24 bit, 48 khz, semi-professional soundcard solution with midi. Although the soundcard does not support DMA directly (a limitation of the PLX9052 interface chip), Rick has developed an innovative scheme of using a user buffer and dumping the result into a kernel ring buffer that provides as little as 2ms latency. You may also find the method/architecture for development of interest to you (see web page and SVN listings). Please provide some of the key information you need so that we can work together most effectively. Answering some the questions above would be a good way to start. We would welcome your feedback so that we can incorporate into the GL project codebase. After your feedback has been incorporated in the code and testing is completed, we will be pinging you again (the second time) to let you know we are ready to put the code in the alsa tree. Regards, Mike Mazarick mazarick(a)bellsouth.net

2 1

[alsa-devel] ioctl(arg) - uninitialised byte(s) in alsa lib
by Mathieu Monney 12 Mar '08

12 Mar '08

Hi all, I'm currently working on a small audio stack on top of alsa and I'm getting some "Syscall param ioctl(arg) contains uninitialized byte(s)" errors when I run my program using valgrind. I don't know if it is a bug in my program or in alsa lib. What I'm sure is that my program is working even though these errors appear. The dump: ==14279== Syscall param ioctl(arg) contains uninitialised byte(s) ==14279== at 0x40007F2: (within /lib/ld-2.6.1.so) ==14279== by 0x40DE911: snd_pcm_prepare (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x40F2552: (within /usr/lib/libasound.so.2.0.0) ==14279== by 0x40DE911: snd_pcm_prepare (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4F0C: snd_pcm_hw_params (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x80A6599: AlsaConfigureDevice (in /home/mathieu/BProject/WiFi-VoIP/pjsip/pjsip_host_x86/pjsip-apps/bin/pjsua-i686-pc-linux-gnu) ==14279== by 0x80A6DE3: pjmedia_snd_open (in /home/mathieu/BProject/WiFi-VoIP/pjsip/pjsip_host_x86/pjsip-apps/bin/pjsua-i686-pc-linux-gnu) ==14279== by 0x809EC85: start_sound_device (in /home/mathieu/BProject/WiFi-VoIP/pjsip/pjsip_host_x86/pjsip-apps/bin/pjsua-i686-pc-linux-gnu) ==14279== by 0x805EE1E: pjsua_set_snd_dev (in /home/mathieu/BProject/WiFi-VoIP/pjsip/pjsip_host_x86/pjsip-apps/bin/pjsua-i686-pc-linux-gnu) ==14279== by 0x80615AA: pjsua_media_subsys_start (in /home/mathieu/BProject/WiFi-VoIP/pjsip/pjsip_host_x86/pjsip-apps/bin/pjsua-i686-pc-linux-gnu) ==14279== by 0x805AAC5: pjsua_start (in /home/mathieu/BProject/WiFi-VoIP/pjsip/pjsip_host_x86/pjsip-apps/bin/pjsua-i686-pc-linux-gnu) ==14279== by 0x805001B: app_main (in /home/mathieu/BProject/WiFi-VoIP/pjsip/pjsip_host_x86/pjsip-apps/bin/pjsua-i686-pc-linux-gnu) ==14279== ==14279== Syscall param ioctl(arg) contains uninitialised byte(s) ==14279== at 0x40007F2: (within /lib/ld-2.6.1.so) ==14279== by 0x40DE911: snd_pcm_prepare (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4F0C: snd_pcm_hw_params (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x411C213: snd_pcm_direct_initialize_slave (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x4115DFB: snd_pcm_dmix_open (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x4116286: _snd_pcm_dmix_open (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4384: (within /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4A82: (within /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4AF2: snd_pcm_open_slave (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x4100CEF: _snd_pcm_plug_open (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4384: (within /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4A82: (within /usr/lib/libasound.so.2.0.0) ==14279== ==14279== Syscall param ioctl(arg) contains uninitialised byte(s) ==14279== at 0x40007F2: (within /lib/ld-2.6.1.so) ==14279== by 0x40DE7D1: snd_pcm_start (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x411C5DF: snd_pcm_direct_initialize_slave (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x4115DFB: snd_pcm_dmix_open (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x4116286: _snd_pcm_dmix_open (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4384: (within /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4A82: (within /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4AF2: snd_pcm_open_slave (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x4100CEF: _snd_pcm_plug_open (in /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4384: (within /usr/lib/libasound.so.2.0.0) ==14279== by 0x40E4A82: (within /usr/lib/libasound.so.2.0.0) ==14279== by 0x80A6E1B: pjmedia_snd_open (in /home/mathieu/BProject/WiFi-VoIP/pjsip/pjsip_host_x86/pjsip-apps/bin/pjsua-i686-pc-linux-gnu) Thank you, Mathieu Monney

2 2

[alsa-devel] I changed cross-compiler to eabi. But alsa applications don't working.
by Jin-Young Park 12 Mar '08

12 Mar '08

Hello. Yesterday, I was changed cross-compiler to eabi. All components(Kernel, libraries and applications) was re-compiled, no problem. Almost all components are well working, but alsa application do not working. Any clue? Thanks. ------ error messages ------ # madplay-alsa --no-tty-control I.O.U.mp3 MPEG Audio Decoder 0.15.2 (beta) - Copyright (C) 2000-2004 Robert Leslie et al. Title: I.O.U Artist: Carry&Ron ALSA lib pcm_params.c:2135:(snd1_pcm_hw_refine_slave) Slave PCM not usable Access type not available for playback: Invalid argument output: Invalid argument ------ error messages ------ # aplay -M -D hw:0,0 Torn.wav Playing WAVE 'Torn.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo aplay: set_params:896: Broken configuration for this PCM: no configurations available

1 0

[alsa-devel] [patch 0/2] PNP: disable PNP motherboard resources that overlap PCI BARs
by Bjorn Helgaas 12 Mar '08

12 Mar '08

The following two patches fix several problems caused by BIOSes that report PNP motherboard device resources that overlap with PCI BARs. I think these should go in before 2.6.25 because some of these problems showed up in 2.6.24 when we increased PNP_MAX_MEM from 4 to 12, and there's no good way to work around them. Bjorn --

2 3

[alsa-devel] aplay: can't resolve symbol 'snd_dlsym_start
by Pharaoh . 11 Mar '08

11 Mar '08

Hi, I have written an user space plugin and the plugin shared library is copied on board appropriately, libasound.so is also copied. When I try: #aplay -D omx test.wav //omx is my plugin I get following error: aplay: can't resolve symbol 'snd_dlsym_start Any idea what is the problem? -pharaoh

2 9

Re: [alsa-devel] ICE1724 - File descriptor in bad state when capturing
by Clemens Ladisch 11 Mar '08

11 Mar '08

Pavel Hofman wrote: > Clemens Ladisch wrote: > > Pavel Hofman wrote: > > > Whereas for the broken analog input, the sequence is > > > > > > 1. snd_pcm_lib_read1 with SNDRV_PCM_STATE_PREPARED - returns 0 > > > 2. snd_pcm_lib_read1 with SNDRV_PCM_STATE_SETUP - returns -EBADFD > > > > I'd guess that your trigger callback fails somehow, bit this is > > hard to determine without the source code. > > Thanks, I will do more testing in the evening. Just in case, I am > including the relevant files. I moved all rate-relevant stuff to > card-specific routines, redefined in juli.c. The trigger code was not > changed at all. > > Perhaps those new snd_pcm_hardware structs in juli.c (I do not know the > exact meaning of the _bytes_ ones)? These values are in bytes (and not in frames). It's possible that the AK4114 code stops the stream because it thinks that the input sample rate has changed. Try uncommenting the printk in i2c/other/ak4114.c. Regards, Clemens

2 2

[alsa-devel] ALSA Version change
by Chris Healy 11 Mar '08

11 Mar '08

Currently, I am using a 2.6.19.2 kernel with ALSA version 1.0.13. This is on an i.MX31 ARM11 platform. (This is what it came with.) We want to use a codec that currently has and ASoC supported driver so it seems best that we move forward to a newer version of ALSA. (1.0.14 or later has ASoC.) If we are going to the trouble of moving from 1.0.13 to a later version, does it make sense to port to 1.0.14 or 1.0.16? It makes sense that moving to 1.0.14 would take the least effort, but obviously, 1.0.16 has bug fixes and features. Do you think there is a large delta porting wise between moving to 1.0.16 instead of 1.0.14. (The assumption is that we have to move over to the later alsa-lib and alsa-utils, correct?) The other question we have is in reference to the max number of cards we are working with. This is an embedded system and we want to control 16 audio codecs, (cards). We won't be using the PCM interfaces of these cards, but we do need to control the codecs through the mixer interface. I have seen limitations previously alluding to a maximum of 8 cards but this was a few years ago. Is this true with the most recent versions, and if so, any ideas on what is necessary to change this? Thanks, Chris

3 2