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

[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 . 12 Mar '08

12 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

[alsa-devel] ICE1724 - File descriptor in bad state when capturing
by Pavel Hofman 11 Mar '08

11 Mar '08

Hi, I have most of the ESI Juli driver working, but I have hit a problem with the capture stream. I had to modify some ice1724.c code to allow redefining clock-related functions in the actual card file (Juli has a different clocking scheme), but all the DMA code is left intact, as well as the methods defining the capture stream. The ice1724 vu-meters detect input ADC data, I can hear correct sound when setting the internal mixer to H/W-In. Yet, when trying to record, I get arecord -v -D hw:0,0,0 -r 44100 -f S32_LE -c2 .... RIFF$WAVEfmt ... data arecord: pcm_read:1346: read error: File descriptor in bad state At the same time, my second Envy24-based card Prodigy192 (uses the original methods in ice1724.c) works OK, arecord gives no errors. Swapping the cards using the model parameter (to swap the /dev/snd/pcmCXDXc device file) makes no difference. Thank you for any hints of where I should focus my attention to. I am not attaching the patches, as they are rather complicated. If you find that important, I will send the preliminary version. Pavel Hofman.

3 4

[alsa-devel] edirol m100fx
by J Brumbagh 11 Mar '08

11 Mar '08

I saw a post on the soundcard list to contact you if I have a Roland/Edirol M-100fx 10 channel mixer. I do have one and I would like to help out in anyway I can. The post seems to have been from Clemens Ladisch but I'm not sure if that matters. Please let me know how I can be of assistance. On another note I also have an internal sound card lspci lists as an ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02)" This card has a headphone jack that seconds as a MiniTOSlink fiber optic jack. The sound card works fine however the fiber optic doesn't work. I think I do have windows drivers for this device on the OEM XP installation cd I have. I would greatly like to have this working properly and am also willing to help with the development. Thanks, Justin ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

2 1

[alsa-devel] What does fifo_size mean in struct snd_pcm_hardware?
by Jin-Young Park 11 Mar '08

11 Mar '08

Hello. Struct snd_pcm_hardware have fifo_size field. The fifo place in audio interface(AC97, I2S) or in ALSA architecture? What does it meaning? I could not find it that related implementation in ALSA source code. Thanks.

2 1

Re: [alsa-devel] X-Fi support in ALSA.
by Spike 11 Mar '08

11 Mar '08

> Hi, > > I have now had a chance to read some of the specs of the X-Fi cards. > aka. emu20k1. > It turns out that some of the X-Fi cards have a compatibility mode. > By default, they boot up in compatibility mode. > The interesting point is that this "compatibility mode" is in fact > the intel-HD standard so could use the intel-hda driver. > For one X-Fi card with IDs: > Device 1102:0009 Subsystem: 1102:0010 > works a bit with the ALSA hda-intel driver. > So far, the off the shelf hda-intel driver, with simple PCIs > adjustment, works for the above card, but only sound capture works so > far, so probably some quirk would be needed. > This compatibility mode works with the Windows Vista UAA drivers. > > Not all X-Fi cards support with compatibility mode. For example, any > card with (after a cold boot into Linux) > Device 1102:0005 Subsystem: xxxx:xxxx > will be X-Fi only. > > With regard to actual full X-Fi support, I am still in the progress of > creating a GPL emu20k1.h file, that is the first step towards an > snd-emu20k1 native ALSA driver. > > James Hello, That first ID is an X-Fi Xtreme Audio PCIe (CA0110-IBG) is it not? Not a real EMU20K1 based X-Fi, fully software driven, and from what I read its just a PCIe variation of the old CA0106. This thing will probably work with snd-ca0106 if creative kept to their old tactics regarding their low end X-Fi products. As for supporting the real X-Fi's, this is great news, its been a very longtime coming. One just has to question Creative's motives behind finally releasing the datasheets out of the blue like that after more than 2 years of trying to get them. Are these sheets under an NDA? Full support of an X-Fi will probably also need a firmware loader. If the PCIe CA0110-IBG doesn't share any common traits with a full blown EMU20K1, then I think the real X-Fi's should be focused on first as many more people are going to have these real X-Fi's that are useless to them at the moment, (about 3 years remember). I'll be around to help test code and can try anything you will require to help out supporting a real X-Fi card. 02:08.0 Multimedia audio controller: Creative Labs SB X-Fi [1102:0005] Subsystem: Unknown device 415a:0034 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at a400 [size=32] Memory at efc00000 (64-bit, non-prefetchable) [size=2M] Memory at e8000000 (64-bit, non-prefetchable) [size=64M] Bren

2 1