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

[alsa-devel] possible recursive locking in snd_pcm_playback_ioctl()
by Chuck Ebbert 26 Feb '09

26 Feb '09

https://bugzilla.redhat.com/show_bug.cgi?id=486729 [ INFO: possible recursive locking detected ] 2.6.29-0.137.rc5.git4.fc11.x86_64 #1 --------------------------------------------- pulseaudio/4381 is trying to acquire lock: (&substream->self_group.lock/1){....}, at: [<ffffffffa0161309>] snd_pcm_action_group+0x53/0x217 [snd_pcm] but task is already holding lock: (&substream->self_group.lock/1){....}, at: [<ffffffffa0161309>] snd_pcm_action_group+0x53/0x217 [snd_pcm] other info that might help us debug this: 4 locks held by pulseaudio/4381: #0: (snd_pcm_link_rwlock){....}, at: [<ffffffffa0160450>] snd_pcm_stream_lock_irq+0x1d/0x2d [snd_pcm] #1: (&substream->self_group.lock){....}, at: [<ffffffffa016045c>] snd_pcm_stream_lock_irq+0x29/0x2d [snd_pcm] #2: (&substream->group->lock){....}, at: [<ffffffffa0161619>] snd_pcm_action+0x33/0x90 [snd_pcm] #3: (&substream->self_group.lock/1){....}, at: [<ffffffffa0161309>] snd_pcm_action_group+0x53/0x217 [snd_pcm] stack backtrace: Pid: 4381, comm: pulseaudio Not tainted 2.6.29-0.137.rc5.git4.fc11.x86_64 #1 Call Trace: [<ffffffff8106faa1>] __lock_acquire+0x83b/0xc0d [<ffffffff8106e500>] ? check_usage_backwards+0x4a/0x53 [<ffffffff8106ff05>] lock_acquire+0x92/0xc0 [<ffffffffa0161309>] ? snd_pcm_action_group+0x53/0x217 [snd_pcm] [<ffffffff81394c10>] _spin_lock_nested+0x34/0x67 [<ffffffffa0161309>] ? snd_pcm_action_group+0x53/0x217 [snd_pcm] [<ffffffffa0161309>] snd_pcm_action_group+0x53/0x217 [snd_pcm] [<ffffffffa016164f>] snd_pcm_action+0x69/0x90 [snd_pcm] [<ffffffffa016045c>] ? snd_pcm_stream_lock_irq+0x29/0x2d [snd_pcm] [<ffffffffa0161690>] snd_pcm_stop+0x1a/0x1c [snd_pcm] [<ffffffffa0161722>] snd_pcm_drop+0x90/0xa6 [snd_pcm] [<ffffffffa01642e9>] snd_pcm_common_ioctl1+0xb76/0xc26 [snd_pcm] [<ffffffff8101781b>] ? native_sched_clock+0x2d/0x5a [<ffffffff810170b5>] ? sched_clock+0x9/0xc [<ffffffff8106d04d>] ? lock_release_holdtime+0x2c/0x11d [<ffffffff81167865>] ? avc_has_perm_noaudit+0x444/0x497 [<ffffffff8116788c>] ? avc_has_perm_noaudit+0x46b/0x497 [<ffffffff81167458>] ? avc_has_perm_noaudit+0x37/0x497 [<ffffffffa01648ed>] snd_pcm_playback_ioctl1+0x282/0x29f [snd_pcm] [<ffffffff8106d04d>] ? lock_release_holdtime+0x2c/0x11d [<ffffffffa016529d>] snd_pcm_playback_ioctl+0x2f/0x33 [snd_pcm] [<ffffffff810ee59b>] vfs_ioctl+0x22/0x87 [<ffffffff810eea6b>] do_vfs_ioctl+0x46b/0x4ac [<ffffffff810eeb02>] sys_ioctl+0x56/0x79 [<ffffffff8101133a>] system_call_fastpath+0x16/0x1b

1 0

[alsa-devel] Rationale behind snd_pcm_htimestamp()
by Lennart Poettering 25 Feb '09

25 Feb '09

Heya! I am interested to query the current delay and the current avail atomically together with the timestamp when they were current. Apparantly there is now a function that can get the former two atomically (snd_pcm_avail_delay()) and another one that gets the latter two atomically (snd_pcm_htimestamp()). _avail_delay() seems to sync the hw index data, _htimestamp() apparently not. Hence I had assume that first calling _avail_delay() and then _htimestamp() one after the other without any further access would return the same avail value. Turns out, my test results on an USB card show that this assumption is not true. An alternative way seemed to be to go via the snd_pcm_status structure. However querying that seems not to sync the hw index data. Hmm... so let's call snd_pcm_hwsync() right before querying the struct -- as it turns out however, that function is now deprecated. So which function should I call? The doxygen comments of _hwsync() kind of suggest in a way to call snd_pcm_avail_update(), whose doxygen comments however declare that it does in fact *not* sync the hw state either, but suggest to use snd_pcm_avail() for that. Ok, so I am now tempted to first call snd_pcm_avail() and then snd_pcm_status() and have all three values atomically. But unfortunately that's not the case. Again the avail value of the two calls differs sometimes. How can I query the three values atomically? Can i do that at all? Also, snd_pcm_hw_params_is_monotonic() always returns 0 on all my devices. I am calling that function after having set both HW and SW params. Kernel is 2.6.27, alsa-libs is 1.0.19. The kernel itself does monotonic/hrtimers just fine. Hmm, last week I started this discussion about "snd_pcm_busy_for()" (aka granularity API). Who can I bribe to get an API like this? Although snd_pcm_busy_for() would suit me much better than just a call to query the granularity, I'd be happy with either... Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 4

[alsa-devel] Timer instability
by Lennart Poettering 25 Feb '09

25 Feb '09

Heya! As you might now PulseAudio schedules audio by system timers, not by sound card interrupts. Unfortunately there are are couple of issues with the reliability of the timing/buffering information we get from ALSA. For example, on an ens1371 I have tracked down the following issue: I use the full buffer that the sound card provides (64K, i.e. 371ms). I sleep for about 350 ms, then fill up again, and sleep 350ms, and so and so on. Everytime I wake up I check snd_pcm_avail() and write exactly as much as this call tells me to. I also listen to POLLOUT events on the fd, however I call snd_pcm_sw_params_set_period_event(, 0) for it to make sure I actually don't get any real events on that. After a couple of minutes of running this loop I can reliably reproduce that _avail() tells me I should fill the buffer up, I do so, query it again and it shows the buffer is filled up. I then go to sleep but immediately get POLLIN (although I shouldnt, given that I called snd_pcm_sw_params_set_period_event()), wake up again, call snd_pcm_avail() and according to it the buffer ran completely empty. The poll() took less than 1 ms time, and the last thing I did before going to sleep was checking that the buffer was full. So certainly ALSA is lying to me here... The buffer couldn't have run empty in less than 1 ms! The same with real numbers as one example: 1. ... we are woken up 2. _avail() returns 15496 samples (i.e. 350ms to fill up) 3. we gather and write 15496 samples 4. _avail() returns 48 samples, which we consider "filled up enough" to go to sleep 5. we call poll() 6. after < 1ms we are woken up by a POLLIN (which we actually thought we had explicitly disabled) 7. _avail() returns 16448 samples (i.e. 372ms to fill up -- larger than the actual buffer of 16384 samples!) This smells a lot like some kind of overflow to me, given that in every case where I could reproduce this it was possible to 'fix' the issue by substracting the buffer size from the _avail() after the poll(). After that substraction the value started to make sense again. (i.e. in the example above it then becomes 64 samples, which is reasonable after sleep less than 1ms I guess). The stop threshold is set to the boundary here btw. If necessary I could extract a test case for this, but my hope that you guys might have an idea what goes on without a test case, given that this smells so "overflowy" ;-) And of course, how come ALSA triggers POLLIN if I asked it not to? This is alsa-libs 1.0.19 on a 2.6.27 kernel. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

5 36

[alsa-devel] [PATCH] snd-powermac: timeout reaches -1
by Roel Kluin 25 Feb '09

25 Feb '09

If unsuccessful, timeout reaches -1 after the loop. Signed-off-by: Roel Kluin <roel.kluin(a)gmail.com> --- diff --git a/sound/ppc/burgundy.c b/sound/ppc/burgundy.c index f860d39..45a7629 100644 --- a/sound/ppc/burgundy.c +++ b/sound/ppc/burgundy.c @@ -35,7 +35,7 @@ snd_pmac_burgundy_busy_wait(struct snd_pmac *chip) int timeout = 50; while ((in_le32(&chip->awacs->codec_ctrl) & MASK_NEWECMD) && timeout--) udelay(1); - if (! timeout) + if (timeout < 0) printk(KERN_DEBUG "burgundy_busy_wait: timeout\n"); }

2 1

Re: [alsa-devel] No sound for HP Pavilion DV4z
by aeleneski＠comcast.net 25 Feb '09

25 Feb '09

Alright. Well, it again seems like a no go. Ran all the commands, still no sound. Upon starting Amarok, I receive the error "xine was unable to initialize any audio drivers." Then also when I do aplay -l I get: **** List of PLAYBACK Hardware Devices **** card 1: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 Attached is the alsa-info text. Thanks again. Andrew ----- Original Message ----- From: "Takashi Iwai" <tiwai(a)suse.de> To: aeleneski(a)comcast.net Cc: alsa-devel(a)alsa-project.org Sent: Wednesday, February 11, 2009 1:34:29 AM GMT -05:00 US/Canada Eastern Subject: Re: [alsa-devel] No sound for HP Pavilion DV4z At Tue, 10 Feb 2009 23:58:19 +0000 (UTC), aeleneski(a)comcast.net wrote: > > Ok, well I tried this: > > The above might be not suffice to give the initialization before the > parser. Try to call hda-verb like the following instead: > > hda-verb /dev/snd/hwC0D0 0x0d 0x71c 0x10 > hda-verb /dev/snd/hwC0D0 0x0d 0x71d 0x11 > hda-verb /dev/snd/hwC0D0 0x0d 0x71e 0x17 > hda-verb /dev/snd/hwC0D0 0x0d 0x71f 0x90 > > then > > echo 1 > /sys/class/sound/hwC0D0/reconfig > > I started my system, changed to probe_only=1. Ran the commands above, and > removed probe_only=1. > Upon shutdown during restart, I again heard the speakers crackle. When the > system came back up, no sound. Ah no, you don't have to restart the system at all. Maybe I wasn't clear enough. The sequence above itself will make your sound system already usable. (and you don't have to probe_only=1 option.) Just use your sound apps after the sequence above after checking the mixer status. If it still doesn't work, run alsa-info and attach the outupt again. Also, show the kernel message, too. Takashi > > ----- Original Message ----- > From: "Takashi Iwai" <tiwai(a)suse.de> > To: aeleneski(a)comcast.net > Cc: alsa-devel(a)alsa-project.org > Sent: Tuesday, February 10, 2009 6:34:02 AM GMT -05:00 US/Canada Eastern > Subject: Re: [alsa-devel] No sound for HP Pavilion DV4z > > At Mon, 09 Feb 2009 18:24:57 +0100, > I wrote: > > > > At Mon, 9 Feb 2009 17:18:59 +0000 (UTC), > > aeleneski(a)comcast.net wrote: > > > > > > Thanks for your time and all these suggestions. Still no luck though. > > > > > > Seems like you might not be able to have two files ending in alsa-base in > > > the /etc/modprobe.d/ folder. That was the reason for the orange speaker > > > indicator. I had > > > alsa-base and backup-alsa-base, for some reason it was grabbing the > settings > > > from the backup. > > > > Ah, yes, module-init-tools doesn't check every backup file suffix. > > Better to remove completely old files. > > > > > Anyway, with probe only, orange sound indicator, when doing aplay -l I get > > > > > > **** List of PLAYBACK Hardware Devices **** > > > card 1: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI] > > > Subdevices: 1/1 > > > Subdevice #0: subdevice #0 > > > > With probe_only option, it doesn't make sense to run aplay. This > > option basically means "probe codecs but don't set up for use yet". > > This is useful to check the raw setup by BIOS before overriding or > > modifying by the driver. > > > > One thing we can try is to add the pin config dynamically then > > reconfigure. For example, load the driver with probe_only=1, then > > do the following as root: > > > > echo 0x0d 0x71c 0x10 > /sys/class/sound/hwC0D0/init_verbs > > echo 0x0d 0x71d 0x11 > /sys/class/sound/hwC0D0/init_verbs > > echo 0x0d 0x71e 0x17 > /sys/class/sound/hwC0D0/init_verbs > > echo 0x0d 0x71f 0x90 > /sys/class/sound/hwC0D0/init_verbs > > The above might be not suffice to give the initialization before the > parser. Try to call hda-verb like the following instead: > > hda-verb /dev/snd/hwC0D0 0x0d 0x71c 0x10 > hda-verb /dev/snd/hwC0D0 0x0d 0x71d 0x11 > hda-verb /dev/snd/hwC0D0 0x0d 0x71e 0x17 > hda-verb /dev/snd/hwC0D0 0x0d 0x71f 0x90 > > then > > echo 1 > /sys/class/sound/hwC0D0/reconfig > > Takashi > >

3 9

[alsa-devel] Docking stations
by Lennart Poettering 25 Feb '09

25 Feb '09

Heya, there's now some support to be notified about docking station events in the kernel. It probably would make a lot of sense if PulseAudio would listen for these and reprogram the alsa control stuff to switch over to the audio jacks of the docking station and back. I am wondering if there is any defined scheme for doing this switching? i.e. is there an established name for a mixer element that needs to be switched for this? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 1

Re: [alsa-devel] Configuring a TWL GPIO pin as an interrupt
by Lopez Cruz, Misael 24 Feb '09

24 Feb '09

> On Sunday 22 February 2009, Lopez Cruz, Misael wrote: > > In the particular case of ALSA SoC, could the machine/board > > driver be a better place to handle all GPIO/IRQ configuration? > > That driver also contains only board specific code. > > It'd be best of the ASoC stuff could sit with all the other > board-specfic init code, in arch/*/mach-*/board-*.c files, > but I understand those interfaces are not yet stable enough > to support that ... that's why they're in sound/soc/*/*.c > files instead. > > In any case ... everything I said still stands. If you're > doing this for ASoC, you'll need some way to pass data to the > ASoC board-specific code from normal board-specific code, > since some of the relevant config data is not static. I think that if I move the platform_device registration from machine driver to board file I can append jack detection information (gpio pin, irq) through "platform_data" of "dev" field in platform_device structure. And then in the "probe" part in ASoC machine driver I can receive it. Could that be correct? Any other better/standard option? > The current ASoC model seems to be biased towards static > configurations. Notice how it's got to create its own > platform_device nodes ... it can't easily use the standard > mechanisms for associating platform_data or archdata with > those nodes, ditto clocks.

2 3

Re: [alsa-devel] [Fwd: HP DV4 1155 SE - No Sound through speakers...]
by Jean-Pierre André 24 Feb '09

24 Feb '09

Hi, > Hi all, I have an HP DV4 1155-SE, I've been unable to get sound working > through the speakers, although it does work through the headhpones. I ran > alsa-.upgrade which downloaded compiled, and installed 1.0.19 - still no > luck. > I have the same IDT codec 92HD71B7X on another HP DV4 model, and I have tracked the problem to be the kernel configuring IRQ 22 through the APIC, but interrupts triggerring IRQ 20 (on kernel 2.6.27 and alsa 1.0.19). It would be interesting if you could confirm this by analyzing /proc/interrupts. The workarounds I know of are : - adding irqpoll to the boot options, - or adding noapic to the boot options, - using mplayer to play music. There are with option "snd-hda-intel model=hp-m4" (this option is for HP DV5/DV7, but HP DV4 is probably different) I have not enough knowledge to tell where the problem lies : kernel, apic, alsa. Regards Jean-Pierre > I ran alsa-info, output here: > http://www.alsa-project.org/db/?f=844b7ee6468067460e17b7fc694e49052072a26f > > I filed a bug, here: > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4374 > > Any ideas? >

4 32

[alsa-devel] Patch for possible race with /proc/asound symlinks in core/info.c
by Brad Bosch 24 Feb '09

24 Feb '09

Jaroslav, I discovered and fixed an ALSA oops in a very old kernel (2.6.5) used in an embedded application and looking at the latest kernels, it's not clear to me that this was ever completely fixed in newer kernels. I'm sending this email so someone who understands the interactions between the USB and ALSA subsystems better than I do can determine if a similar fix might be required in the newer kernels. In the old kernel, the oops often happens when a USB device is unplugged and then a device with the same ID (or the same device) is immediately plugged back in before the old device is completely cleaned up. The included patch resolves the problem in that kernel. The problem was that two cards were creating symbolic links in /proc/asound with the same name (id) but pointing to differen't cards. The proc subsystem apparently allowed this. Later, when one of the entries is removed (using it's name), the wrong entry may be removed, freeing the wrong struct proc_dir_entry and leaving a pointer to the freed memory in the other card's proc_root_link member. Later when that USB device is unplugged and snd_info_card_disconnect() is called, snd_remove_proc_entry() will reference the name member of struct proc_dir_entry which by now may be changed, or even null. It turns out to be trivial to avoid this problem by simply not storing the pointer to the proc_dir_entry as we don't need it anyway to determine the name of the link to remove. Instead, for the case of the symbolic link, we call remove_proc_entry directly using the card id for the link name (just as we did when it was created). I don't know if two symbolic links are ever created in /proc/asound with the same name in the newer kernels or newer ALSA code and in fact, I haven't been able to reproduce the problem there. However, since the patch reduces both the data and code size, and eliminates a potential crash, you may want to apply it anyway. This patch won't apply directly to newer kernels because of minor changes, but it's trivial to apply by hand. Let me know if you need me to re-base the patch. --Brad Index: sound/core/info.c =================================================================== RCS file: /cvs/kernels/kernel_2_6_5/sound/core/info.c,v retrieving revision 1.1.4.1.10.1 diff -u -r1.1.4.1.10.1 info.c --- sound/core/info.c 22 Feb 2006 14:06:25 -0000 1.1.4.1.10.1 +++ sound/core/info.c 20 Feb 2009 02:05:01 -0000 @@ -618,7 +618,6 @@ p = proc_symlink(card->id, snd_proc_root, card->proc_root->name); if (p == NULL) return -ENOMEM; - card->proc_root_link = p; return 0; } @@ -629,10 +628,7 @@ int snd_info_card_free(snd_card_t * card) { snd_assert(card != NULL, return -ENXIO); - if (card->proc_root_link) { - snd_remove_proc_entry(snd_proc_root, card->proc_root_link); - card->proc_root_link = NULL; - } + remove_proc_entry(card->id, snd_proc_root); if (card->proc_root) { snd_info_unregister(card->proc_root); card->proc_root = NULL; Index: include/sound/core.h =================================================================== RCS file: /cvs/kernels/kernel_2_6_5/include/sound/core.h,v retrieving revision 1.1.4.1 diff -u -r1.1.4.1 core.h --- include/sound/core.h 15 Apr 2005 21:45:13 -0000 1.1.4.1 +++ include/sound/core.h 20 Feb 2009 02:05:02 -0000 @@ -152,7 +152,6 @@ snd_info_entry_t *proc_root; /* root for soundcard specific files */ snd_info_entry_t *proc_id; /* the card id */ - struct proc_dir_entry *proc_root_link; /* number link to real id */ struct snd_monitor_file *files; /* all files associated to this card */ struct snd_shutdown_f_ops *s_f_ops; /* file operations in the shutdown state */

2 3

[alsa-devel] Standard mixer control names
by Lennart Poettering 24 Feb '09

24 Feb '09

Heya! I'd like to add functionality to PulseAudio to allow a simplified selection of capture input (i.e. "Mic", "Line-In", ...) and playback outputs ("Headphones", "Line-Out", ...) for ALSA cards. By "simplified" I mean that only one input and output shall be active at a time. Also, some more nonsense items shall be filtered out (i.e. recording from "Phone"). Hence, basically I want to compile a list of available and whitelisted inputs and outputs and allow the user to select exactly one from each. ALSA is making that very hard to implement something like this because every driver seems to wrap input/output selection differently. On one card I have only has a couple of cswitches (snd-es1371). The same one has an enum "Mic Select". Another card has an enum "Input Source", but no cswitches (a HDA chip). The "ControlNames.txt" file in the kernel seems to suggest that there is an element "Capture Source". For playback it seems that some cards have a a headphone switch, and others a headphone slider (which i guess makes sense). Now, the question, how should I implement this? For playback the handling is easy as long as there is only one element to deal with, but what about capture? One option would be to simply go by cswitch and nothing else. Or go by "Input Source" and nothing else. Or combine some form. Now I'd of course prefer if the drivers get fixed to use a single element naming scheme only. Is there any chance to get that? And which one would that be? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

5 7