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

[alsa-devel] PCM parameters in file plugin
by Pavel Hofman 29 Jan '09

29 Jan '09

Hello, I am working on a file plugin patch to allow adding PCM parameters (rate, format) to the name of the file created (plus the ability to run an external command via popen, such as upsampling with sox). I got stuck in trying to obtain these parameters in pcm_file.c:_snd_pcm_file_open(). Is it actually possible or the information is not available at the time of opening the file (and the whole patch is thus nonsense)? Thanks a lot for help. Pavel.

3 10

[alsa-devel] [PATCH] sscape: update Kconfig description about SoundScape cards
by Krzysztof Helt 29 Jan '09

29 Jan '09

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> The SoundScape driver handles more cards then described. --- sound/isa/Kconfig | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig index cf6c01d..7d80186 100644 --- a/sound/isa/Kconfig +++ b/sound/isa/Kconfig @@ -378,14 +378,17 @@ config SND_SGALAXY will be called snd-sgalaxy. config SND_SSCAPE - tristate "Ensoniq SoundScape PnP driver" + tristate "Ensoniq SoundScape driver" select SND_HWDEP select SND_MPU401_UART select SND_WSS_LIB help - Say Y here to include support for Ensoniq SoundScape PnP + Say Y here to include support for Ensoniq SoundScape soundcards. + The PCM audio is supported on SoundScape Classic, Elite, PnP + and VIVO cards. The MIDI support is very experimental. + To compile this driver as a module, choose M here: the module will be called snd-sscape. -- 1.5.2.2 ---------------------------------------------------------------------- Promocja w Speak Up. 3 miesiace angielskiego gratis. Sprawdz teraz i wypelnij formularz! >> http://link.interia.pl/f2019

2 1

[alsa-devel] [PATCH] cmi8330: add MPU-401 support
by Krzysztof Helt 29 Jan '09

29 Jan '09

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> Add MPU-401 port support for the chip. Also, update some error messages and description. --- sound/isa/Kconfig | 1 + sound/isa/cmi8330.c | 42 ++++++++++++++++++++++++++++++++++++------ 2 files changed, 37 insertions(+), 6 deletions(-) diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig index 7d80186..ed798bf 100644 --- a/sound/isa/Kconfig +++ b/sound/isa/Kconfig @@ -95,6 +95,7 @@ config SND_CMI8330 select SND_WSS_LIB select SND_SB16_DSP select SND_OPL3_LIB + select SND_MPU401_UART help Say Y here to include support for soundcards based on the C-Media CMI8330 chip. diff --git a/sound/isa/cmi8330.c b/sound/isa/cmi8330.c index 1154379..9ca8122 100644 --- a/sound/isa/cmi8330.c +++ b/sound/isa/cmi8330.c @@ -31,11 +31,11 @@ * To quickly load the module, * * modprobe -a snd-cmi8330 sbport=0x220 sbirq=5 sbdma8=1 - * sbdma16=5 wssport=0x530 wssirq=11 wssdma=0 + * sbdma16=5 wssport=0x530 wssirq=11 wssdma=0 fmport=0x388 * * This card has two mixers and two PCM devices. I've cheesed it such * that recording and playback can be done through the same device. - * The driver "magically" routes the capturing to the AD1848 codec, + * The driver "magically" routes the capturing to the CMI8330 codec, * and playback to the SB16 codec. This allows for full-duplex mode * to some extent. * The utilities in alsa-utils are aware of both devices, so passing @@ -52,6 +52,7 @@ #include <sound/core.h> #include <sound/wss.h> #include <sound/opl3.h> +#include <sound/mpu401.h> #include <sound/sb.h> #include <sound/initval.h> @@ -81,6 +82,8 @@ static long wssport[SNDRV_CARDS] = SNDRV_DEFAULT_PORT; static int wssirq[SNDRV_CARDS] = SNDRV_DEFAULT_IRQ; static int wssdma[SNDRV_CARDS] = SNDRV_DEFAULT_DMA; static long fmport[SNDRV_CARDS] = SNDRV_DEFAULT_PORT; +static long mpuport[SNDRV_CARDS] = SNDRV_DEFAULT_PORT; +static int mpuirq[SNDRV_CARDS] = SNDRV_DEFAULT_IRQ; module_param_array(index, int, NULL, 0444); MODULE_PARM_DESC(index, "Index value for CMI8330 soundcard."); @@ -111,6 +114,10 @@ MODULE_PARM_DESC(wssdma, "DMA for CMI8330 WSS driver."); module_param_array(fmport, long, NULL, 0444); MODULE_PARM_DESC(fmport, "FM port # for CMI8330 driver."); +module_param_array(mpuport, long, NULL, 0444); +MODULE_PARM_DESC(mpuport, "MPU-401 port # for CMI8330 driver."); +module_param_array(mpuirq, int, NULL, 0444); +MODULE_PARM_DESC(mpuirq, "IRQ # for CMI8330 MPU-401 port."); #ifdef CONFIG_PNP static int isa_registered; static int pnp_registered; @@ -153,6 +160,7 @@ struct snd_cmi8330 { #ifdef CONFIG_PNP struct pnp_dev *cap; struct pnp_dev *play; + struct pnp_dev *mpu; #endif struct snd_card *card; struct snd_wss *wss; @@ -169,7 +177,7 @@ struct snd_cmi8330 { #ifdef CONFIG_PNP static struct pnp_card_device_id snd_cmi8330_pnpids[] = { - { .id = "CMI0001", .devs = { { "@@@0001" }, { "@X@0001" } } }, + { .id = "CMI0001", .devs = { { "@@@0001" }, { "@X@0001" }, { "@H@0001" } } }, { .id = "" } }; @@ -329,11 +337,15 @@ static int __devinit snd_cmi8330_pnp(int dev, struct snd_cmi8330 *acard, if (acard->play == NULL) return -EBUSY; + acard->mpu = pnp_request_card_device(card, id->devs[2].id, NULL); + if (acard->play == NULL) + return -EBUSY; + pdev = acard->cap; err = pnp_activate_dev(pdev); if (err < 0) { - snd_printk(KERN_ERR "CMI8330/C3D (AD1848) PnP configure failure\n"); + snd_printk(KERN_ERR "CMI8330/C3D PnP configure failure\n"); return -EBUSY; } wssport[dev] = pnp_port_start(pdev, 0); @@ -354,6 +366,17 @@ static int __devinit snd_cmi8330_pnp(int dev, struct snd_cmi8330 *acard, sbdma16[dev] = pnp_dma(pdev, 1); sbirq[dev] = pnp_irq(pdev, 0); + /* allocate MPU-401 resources */ + pdev = acard->mpu; + + err = pnp_activate_dev(pdev); + if (err < 0) { + snd_printk(KERN_ERR + "CMI8330/C3D (MPU-401) PnP configure failure\n"); + return -EBUSY; + } + mpuport[dev] = pnp_port_start(pdev, 0); + mpuirq[dev] = pnp_irq(pdev, 0); return 0; } #endif @@ -502,11 +525,11 @@ static int __devinit snd_cmi8330_probe(struct snd_card *card, int dev) wssdma[dev], -1, WSS_HW_DETECT, 0, &acard->wss); if (err < 0) { - snd_printk(KERN_ERR PFX "(AD1848) device busy??\n"); + snd_printk(KERN_ERR PFX "(CMI8330) device busy??\n"); return err; } if (acard->wss->hardware != WSS_HW_CMI8330) { - snd_printk(KERN_ERR PFX "(AD1848) not found during probe\n"); + snd_printk(KERN_ERR PFX "(CMI8330) not found during probe\n"); return -ENODEV; } @@ -552,6 +575,13 @@ static int __devinit snd_cmi8330_probe(struct snd_card *card, int dev) } } + if (mpuport[dev] != SNDRV_AUTO_PORT) { + if (snd_mpu401_uart_new(card, 0, MPU401_HW_MPU401, + mpuport[dev], 0, mpuirq[dev], + IRQF_DISABLED, NULL) < 0) + printk(KERN_ERR PFX "no MPU-401 device at 0x%lx.\n", + mpuport[dev]); + } strcpy(card->driver, "CMI8330/C3D"); strcpy(card->shortname, "C-Media CMI8330/C3D"); -- 1.5.2.2 ---------------------------------------------------------------------- Obdaruj swoja Walentynke ... lub siebie! Wygraj nagrody! Sprawdz >> http://link.interia.pl/f203a

1 0

[alsa-devel] [PATCH] gus: update debug messages
by Krzysztof Helt 29 Jan '09

29 Jan '09

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> Convert some of them to snd_printdd() and update arguments to make them compilable. --- sound/isa/gus/gus_dma.c | 24 +++++++++++++++--------- 1 files changed, 15 insertions(+), 9 deletions(-) diff --git a/sound/isa/gus/gus_dma.c b/sound/isa/gus/gus_dma.c index f45f611..cf8cd3c 100644 --- a/sound/isa/gus/gus_dma.c +++ b/sound/isa/gus/gus_dma.c @@ -45,7 +45,8 @@ static void snd_gf1_dma_program(struct snd_gus_card * gus, unsigned char dma_cmd; unsigned int address_high; - // snd_printk("dma_transfer: addr=0x%x, buf=0x%lx, count=0x%x\n", addr, (long) buf, count); + snd_printdd("dma_transfer: addr=0x%x, buf=0x%lx, count=0x%x\n", + addr, buf_addr, count); if (gus->gf1.dma1 > 3) { if (gus->gf1.enh_mode) { @@ -142,7 +143,9 @@ static void snd_gf1_dma_interrupt(struct snd_gus_card * gus) snd_gf1_dma_program(gus, block->addr, block->buf_addr, block->count, (unsigned short) block->cmd); kfree(block); #if 0 - printk("program dma (IRQ) - addr = 0x%x, buffer = 0x%lx, count = 0x%x, cmd = 0x%x\n", addr, (long) buffer, count, cmd); + snd_printd(KERN_DEBUG "program dma (IRQ) - " + "addr = 0x%x, buffer = 0x%lx, count = 0x%x, cmd = 0x%x\n", + block->addr, block->buf_addr, block->count, block->cmd); #endif } @@ -203,13 +206,16 @@ int snd_gf1_dma_transfer_block(struct snd_gus_card * gus, } *block = *__block; block->next = NULL; -#if 0 - printk("addr = 0x%x, buffer = 0x%lx, count = 0x%x, cmd = 0x%x\n", block->addr, (long) block->buffer, block->count, block->cmd); -#endif -#if 0 - printk("gus->gf1.dma_data_pcm_last = 0x%lx\n", (long)gus->gf1.dma_data_pcm_last); - printk("gus->gf1.dma_data_pcm = 0x%lx\n", (long)gus->gf1.dma_data_pcm); -#endif + + snd_printdd("addr = 0x%x, buffer = 0x%lx, count = 0x%x, cmd = 0x%x\n", + block->addr, (long) block->buffer, block->count, + block->cmd); + + snd_printdd("gus->gf1.dma_data_pcm_last = 0x%lx\n", + (long)gus->gf1.dma_data_pcm_last); + snd_printdd("gus->gf1.dma_data_pcm = 0x%lx\n", + (long)gus->gf1.dma_data_pcm); + spin_lock_irqsave(&gus->dma_lock, flags); if (synth) { if (gus->gf1.dma_data_synth_last) { -- 1.5.2.2 ---------------------------------------------------------------------- Speak Up. Angielski szybko i skutecznie. 3 miesiace nauki gratis. Sprawdz. >> http://link.interia.pl/f2019

1 0

[alsa-devel] (no subject)
by Philippe CARRIERE 29 Jan '09

29 Jan '09

Hi, following is a report of some tests of alsa.1.0.18rc3 in view of support of Tascam US-122L, which might be of interest for you. As a preliminary information, note that I patched my own Fedora kernel and alsa-plugins with Karsten Wiese'patches a few month ago and use regularly Tascam US-122L under Linux which works very fine; I also provide (experimental) packages for Fedora 9 from june 2008 on my web page. Test 1: succeeded - replacement of my own alsa-plugins-usb_stream-1.0.16-4.us122lv05.fc9 by alsa-plugins-usbstream-1.0.18-1.rc3.fc10 on Fedora 9 (using my own patched kernel 2.6.26 including the snd-usb-us122l module). Everything works. Test 2: succeeded - replacement of previous alsa-1.0.16 by alsa.1.0.18-1.rc3 (Fedora packages; thus alsa-driver-1.0.18rc3 not included). Everything works, including Tascam US-122L when using my patched kernel (which includes the snd-usb-us122l module). Test 3: failed - installation of alsa-driver-1.0.18rc3 (succeeded) on Fedora 9 (as weel, I tested with new Fedora 10 beta which includes kernel 2.6.27.rc3); plug in the US-122L leads to error messages from snd-usb-us122l: # cat /var/log/messages ... Oct 11 09:21:51 pollux kernel: usb 2-6: new high speed USB device using ehci_hcd and address 3 Oct 11 09:21:51 pollux kernel: usb 2-6: config 1 interface 1 altsetting 1 bulk endpoint 0x83 has invalid maxpacket 9 Oct 11 09:21:51 pollux kernel: usb 2-6: configuration #1 chosen from 1 choice Oct 11 09:21:51 pollux kernel: usb 2-6: New USB device found, idVendor=0644, idProduct=800e Oct 11 09:21:51 pollux kernel: usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 11 09:21:51 pollux kernel: usb 2-6: Product: US-122L Oct 11 09:21:51 pollux kernel: usb 2-6: Manufacturer: TASCAM Oct 11 09:21:51 pollux kernel: usb 2-6: SerialNumber: no serial number Oct 11 09:21:51 pollux kernel: ALSA /home/Test/alsa-driver-1.0.18rc3/usb/usx2y/../../alsa-kernel/usb/usx2y/usb_stream.c:618: 0 Oct 11 09:21:55 pollux kernel: ALSA /home/Test/alsa-driver-1.0.18rc3/usb/usx2y/../../alsa-kernel/usb/usx2y/us122l.c:329: us122l_start error -14 Oct 11 09:21:55 pollux kernel: snd-usb-us122l: probe of 2-6:1.1 failed with error -5 Oct 11 09:21:55 pollux kernel: usbcore: registered new interface driver snd-usb-us122l and # cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfebfc000 irq 21 US-122L finally not being recognized. Test 4: succeded - same than test 3 for Fedora 9, but using a patched ehci-hcd module (the patch adding some features from the original one by Karsten Wiese not - yet ? - included in kernel 2.6.26). Everything works including of course the US-122L. Question: Thus, a patched ehci-hcd module is required. Is the patch scheduled to appear in kernel 2.6.27 or would it be useful to work for providing a kind of kmod ? Regards Phil. -- Philippe Carriere <philippe-f.carriere(a)wanadoo.fr>

3 6

[RESEND][PATCH] USB: Prevent EHCI ITDs reusage while frame is active: tested by: Philippe Carriere.
by Philippe Carriere 29 Jan '09

29 Jan '09

Hi, I successfully tested the refreshed patch of Karsten using Fedora rawhide packages. Following are some informations on the test: original kernel: 2.6.29-0.53.rc2.git1.fc11.x86_64 patched kernel: Linux 2.6.29-0.53.rc2.git1.ehcius122l.fc11.x86_64 #1 SMP Wed Jan 28 22:48:01 CET 2009 x86_64 x86_64 x86_64 GNU/Linux alsa: alsa-lib-1.0.19-1.fc11, alsa-plugins-usbstream-1.0.18 jack: jack-audio-connection-kit-0.116.1-3.fc11 qjackctl: qjackctl-0.3.3-1.fc10 audacious: audacious-1.5.1-5.fc11 after plugin the Tascam US-122L: [root@pollux Test]# tail /var/log/messages Jan 29 08:05:53 pollux kernel: usb 2-6: new high speed USB device using ehci_hcd and address 4 Jan 29 08:05:53 pollux kernel: usb 2-6: config 1 interface 1 altsetting 1 bulk endpoint 0x83 has invalid maxpacket 9 Jan 29 08:05:53 pollux kernel: usb 2-6: New USB device found, idVendor=0644, idProduct=800e Jan 29 08:05:53 pollux kernel: usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 29 08:05:53 pollux kernel: usb 2-6: Product: US-122L Jan 29 08:05:53 pollux kernel: usb 2-6: Manufacturer: TASCAM Jan 29 08:05:53 pollux kernel: usb 2-6: SerialNumber: no serial number Jan 29 08:05:53 pollux kernel: usb 2-6: configuration #1 chosen from 1 choice Jan 29 08:06:08 pollux kernel: ALSA sound/usb/usx2y/usb_stream.c:457: underrun, status=4294967278 Jan 29 08:06:08 pollux kernel: ALSA sound/usb/usx2y/usb_stream.c:457: underrun, status=4294967278 [root@pollux Test]# cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfebfc000 irq 21 1 [US122L ]: USB US-122L - TASCAM US-122L TASCAM US-122L (644:800e if 0 at 002/004) and jack messages were 08:50:00.226 /usr/bin/jackd -R -P89 -dalsa -dusb_stream:1 -r48000 -p512 -n2 jackd 0.116.1 Copyright 2001-2005 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. 08:50:00.251 JACK was started with PID=6417. loading driver .. apparent rate = 48000 creating alsa driver ... usb_stream:1|usb_stream:1|512|2|48000|0|0| nomon|swmeter|-|32bit ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL usb_stream:1 control open "usb_stream:1" (No such file or directory) configuring for 48000Hz, period = 512 frames (10.7 ms), buffer = 2 periods ALSA: final selected sample format for capture: 24bit little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 24bit little-endian ALSA: use 2 periods for playback 08:50:02.397 Server configuration saved to "/home/Test/.jackdrc". 08:50:02.398 Statistics reset. 08:50:02.547 Client activated. 08:50:02.550 JACK connection change. 08:50:02.558 JACK connection graph change. Tested by .mp3 file playback using audacious (with plugin jack). Additional notes: the previous version of the patch is routinely used by myself, at least some Fedora users using my packages at http://pagesperso-orange.fr/La-page-Web-of-Phil/Tascam_US-122L/Telechargeme… , and under Debian and Ubuntu (Federico Briata web site at http://wiki.briata.org/doku.php?id=testing_us122l_under_linux ) under 2.6.26 and 2.6.27 kernel. Hope it will be soon integrated to 2.6.29 devel. Regards Phil.

1 0

[alsa-devel] Misusing snd_pcm_avail_update()
by Lennart Poettering 29 Jan '09

29 Jan '09

Heya! Currently in the 'glitch-free' logic of PulseAudio I use snd_pcm_avail_update() to estimate how I need to program my system timers for the next wake-up for the next buffer fill-up. For that I assume that the current fill level of the hardware buffer is the hardware buffer size minus what s_p_a_u() returns. I then convert that fill level from sample units to time units, and fix it up by the deviation of the sound card time from the system time. Finally I substract some extra margin just to make sure. This I assumed would tell me how much time will pass until an underrun happens if I don't write anything. Mostly this logic works fine. But on some setups and cases it doesn't. ALSA will signal an underrun much much earlier than what I estimated like this. I am now wondering why? One possibility of course is that s_p_a_u() is not reliable, due to driver issues (there were problems in the HDA driver about this, right?). Also, s_p_a_u() might simply lag behind quite a bit, or -- what I think is most likely -- because samples are popped in larger blocks form the hw playback buffer we reach the underrun much earlier than expected. I do acknowledge that the way i use s_p_a_u() is probably a misuse of the API. I make asssumptions I probably shouldn't make. Now, considering all this I'd like to ask for a new API function that tells me how much time I really have before the next underrun. It probably should just return a value in sample units, leaving it for the application to deal with system/sound card clock deviations. Any opinions on this? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

4 14

[alsa-devel] Strange Config: Fedora 8 running on Amazon EC2
by Patrick Lightbody 29 Jan '09

29 Jan '09

I have a strange request (which is why I'm sending directly to the dev list). I'm trying to run Flash video (v9 or v10) on Firefox 3 on a Fedora 8 image running on Amazon EC2. I don't actually want/need sound (it's of course technically not possible, since EC2 doesn't provide a sound card). Video playback (when watched through VNC) goes fine for a couple minutes, but then the browser and flash lock up entirely. I've looked for ways to tell Firefox and/or Flash to not send audio out, but I've come up empty so far. So now I'm hoping that fixing this error and putting in perhaps some sort of "no op" device might help out. I'm not positive the error is related to ALSA, though the fact that there appear to be a ton of the following logs just before the lockup is suspicious: ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:3985:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM default ALSA lib pcm_hw.c:1240:(_snd_pcm_hw_open) Invalid value for card (these lines repeat over and over again until the crash happens, then it stops promptly) As you can see by the alsa-info output at the following URL, I don't have any running snd modules: http://www.alsa-project.org/db/?f=6b2431d0564b3638cdb798a6d1a21eb73982588c Similarly, I don't have any sound-related devices installed (ie: /dev/audio, etc). My hope in emailing this list is that there may be a solution that causes ALSA to no-op the requests that Firefox/Flash send it's way, potentially solving the lockup I'm experiencing. I would really appreciate any ideas that could be shared. Thank you very much! Patrick

2 2

[alsa-devel] ASoC : underrun messages
by Naveen Krishna Ch 28 Jan '09

28 Jan '09

Hello, I am experiencing some audio issue While playing using aplay some times i see the following messages. (Sorry if the messages are too long) [root@OMAP3 audio_samples]#aplay sample_96K.wav Playing WAVE 'sample_96K.wav' : Signed 16 bit Little Endian, Rate 96000 Hz, Stereo underrun!!! (at least 1307.251 ms long) underrun!!! (at least 554.656 ms long) underrun!!! (at least 988.861 ms long) underrun!!! (at least 554.443 ms long) underrun!!! (at least 987.670 ms long) underrun!!! (at least 995.484 ms long) ^CAborted by signal Interrupt... [root@OMAP3 audio_samples]#aplay sample_48K.wav Playing WAVE 'sample_48K.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo underrun!!! (at least 69.306 ms long) underrun!!! (at least 130.981 ms long) underrun!!! (at least 205.750 ms long) underrun!!! (at least 178.100 ms long) underrun!!! (at least 146.057 ms long) ^CAborted by signal Interrupt... [root@OMAP3 audio_samples]#aplay sample_8K.wav Playing WAVE 'sample_8K.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo ^C^[[AAborted by signal Interrupt... [root@OMAP3 audio_samples]#aplay sample_22K.wav Playing WAVE 'sample_22K.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Stereo ^CAborted by signal Interrupt... [root@OMAP3 audio_samples]#aplay sample_44K.wav Playing WAVE 'sample_44K.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least 1602.264 ms long) underrun!!! (at least 873.078 ms long) underrun!!! (at least 1693.268 ms long) underrun!!! (at least 870.483 ms long) underrun!!! (at least 540.466 ms long) underrun!!! (at least 1122.711 ms long) I am using OMAP3430 + twl4030 ASoC audio codec drivers. I understand that the prints are coming from alsa-lib aplay.c file As a result of the client not reading the buffers fast enough. These are not conditionally reproducible, i see them uncertainly. I saw the same isue with 2.6.26 some one suggested me to find if there is any bug in the asoc layer. Now i am using 2.6.28 kernel from kernel.org but still got the same Can any one suggest me a way to find a fix for this.. -- Cheers (: Naveen Krishna Ch :)

2 2

[alsa-devel] alsa-lib failing at runtime
by Will Wagner 28 Jan '09

28 Jan '09

Hi All, I have found a problem with alsa-lib 1.0.19 running on an embedded arm board. It all compiles ok but aplay fails to play a .wav file and the kernel reports this error: ALSA sound/core/pcm_native.c:2587: unknown ioctl = 0x80184132 Decoding this ioctl it is SNDRV_PCM_IOCTL_CHANNEL_INFO defined in asound.h. The reason it is not working is that the kernel and alsa-lib think that the sndrv_pcm_channel_info struct is different sizes. The definition in asound.h is: struct sndrv_pcm_channel_info { unsigned int channel; off_t offset; /* mmap offset */ unsigned int first; /* offset to first sample in bits */ unsigned int step; /* samples distance in bits */ }; The problem is that when compiling linux it thinks off_t is 4 bytes but when compiling alsa-lib it thought it was 8 bytes. After discussion on the buildroot mailing list (see http://lists.busybox.net/pipermail/buildroot/2009-January/025458.html) it seems like for the kernel off_t is always 4 bytes but for user space it can be either 4 or 8 bytes depending on whether large file support is enabled. It appears that the fix is that the type of offset should be changed to long. Hope this all makes sense. Thanks, Will. -- ------------------------------------------------------------------------ Will Wagner will_wagner(a)carallon.com Development Manager Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ------------------------------------------------------------------------

2 1