Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
At Mon, 27 Apr 2015 13:11:53 +0800, Raymond Yau wrote: 2015-04-27 0:05 GMT+08:00 Takashi Iwai ti...@suse.de: At Sun, 26 Apr 2015 09:20:12 -0600, Glenn Golden wrote: Anyway, just my 2c, and entirely distinct from the issue at hand. Let's get the LED working as intended first. It's likely just a missing quirk application. There was already a quick specific to your device (17aa:215e), but this doesn't include the thinkpad_acpi hook. A patch like below may fix the issue. Give it a try. Seem Thinkpad T510 has Conexant codec instead of realtek Gah, I hate reports without alsa-info.sh output (not a link to somewhere else). Glenn, please attach alsa-info.sh outputs (run it with --no-upload option) and the whole dmesg output after boot. 3.19 should already contain the hook to thinkpad_acpi.c. If anything is missing, you should have a warning indicating it. thanks, Takashi ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
On Fri, Apr 24, 2015, at 22:39, Glenn Golden wrote: in response to the event. What action can be taken to turn on the mute LED? Issue an amixer/pactl/pacmd command to toggle the Master Playback mute state? Speaking as the thinkpad-acpi driver maintainer: Keeping the ThinkPad MUTE LED states in sync is the kernel's job. This is the beginning and the end of it. It clearly is not working properly right now. Possibly the defect is restricted to some thinkpads: Lenovo changes firmware behaviour sometimes. They're good about leaving a knob you can set to get whatever behaviour you want/need. They're not always that good about _testing_ it, though. And we (kernel side) are not that good at either knowing the behaviour exists, or making use of it. Or it might be a simple driver bug that affects every thinkpad with a mute LED. I hope so, because that's much easier to fix. Those are the facts. It doesn't look like there is anything pulse-audio related in this issue: it is a matter for the kernel to fix. Either in the ALSA sublayer, if it is not being able to correctly signal thinkpad-acpi to change Mute LED state, or in thinkpad-acpi if it is not correctly relaying to the thinkpar firmware the desired mute LED state. No, that won't do it, because the LED isn't following the mixer mute state (see earlier posts in this thread). Directly access the LED via some exposed interface to it? No sign that any such any such interface is available in /proc/acpi or /sys/class/leds (see comment #15 in the kernel bugtracker). And it is not going to be made available (in some thinkpads, it cannot even be done: when you change the hardware mute gate state, the EC updates the LED state to match). This is why we will consider any mute led misbehavior to be a kernel issue, to be fixed in the kernel. As I mentioned on the kernel bugtracker, I'm going to take this up with the thinkpad ACPI folks, see if they have any suggestions. I lack the hardware to develop-and-test a fix (I am long overdue for a replacement thinkpad, really. I only have a good T43, and a damaged R60), but I am open to help (and ACK kernel-side patches). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
Thanks for your detailed reply Henrique, clarity much appreciated. Some comments inline. (Btw, an aside: Your post didn't make to the PA list for some reason, at least not yet. Maybe it's being held for moderation? Anyway if any moderators are reading this, please push Henrique's post thru to the list so we have a complete record of the thread, thx.) Henrique de Moraes Holschuh h...@hmh.eng.br [2015-04-25 12:11:59 -0300]: On Fri, Apr 24, 2015, at 22:39, Glenn Golden wrote: in response to the event. What action can be taken to turn on the mute LED? Issue an amixer/pactl/pacmd command to toggle the Master Playback mute state? Speaking as the thinkpad-acpi driver maintainer: Keeping the ThinkPad MUTE LED states in sync is the kernel's job. This is the beginning and the end of it. Yep, I don't think there's any argument on that, at least not from me. That was also the original take from David and Hui in response to the first post on this thread: http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-March/023551.html Based on their responses, this kernel ticket was filed: https://bugzilla.kernel.org/show_bug.cgi?id=96171 If you're interested in the gory details, see the Report attachment there. Imo, the discussion on the kernel bugtracker got off track in terms of establishing what the problem is and what it isn't. Your message here has clarified that. I'm glad to help if I can in getting to the bottom of the problem (see further below.) It clearly is not working properly right now. Possibly the defect is restricted to some thinkpads: Lenovo changes firmware behaviour sometimes. They're good about leaving a knob you can set to get whatever behaviour you want/need. They're not always that good about _testing_ it, though. And we (kernel side) are not that good at either knowing the behaviour exists, or making use of it. Or it might be a simple driver bug that affects every thinkpad with a mute LED. I hope so, because that's much easier to fix. Those are the facts. It doesn't look like there is anything pulse-audio related in this issue: it is a matter for the kernel to fix. Either in the ALSA sublayer, if it is not being able to correctly signal thinkpad-acpi to change Mute LED state, or in thinkpad-acpi if it is not correctly relaying to the thinkpar firmware the desired mute LED state. No, that won't do it, because the LED isn't following the mixer mute state (see earlier posts in this thread). Directly access the LED via some exposed interface to it? No sign that any such any such interface is available in /proc/acpi or /sys/class/leds (see comment #15 in the kernel bugtracker). And it is not going to be made available (in some thinkpads, it cannot even be done: when you change the hardware mute gate state, the EC updates the LED state to match). This is why we will consider any mute led misbehavior to be a kernel issue, to be fixed in the kernel. Actually, I'd like to debate -- this is probably not the right place -- that a more flexible solution looking forward, if feasible, would be to keep the mute key as softkey just as now in 3.19, but also expose userspace interfaces to both the HW mute and the mute LED on machines on which it is possible to do so. This everything bagel approach would give everyone (individual users as well as desktop environment designers) the flexibility to handle muting (and express mute state) in whatever way suits them. Imo, a problem with the present state of affairs in 3.19 (assuming a working mute LED that correctly follows Playback Master mute state) is that the LED is one bit of information that has to express two bits of mute state: One for headphones and one for speaker. In contrast, in 3.18, the LED had a simple, immutable semantic because it was tied to the HW mute gate: If the LED was lit, no sound could come out of the speaker, period. So in the common situation where you want to avoid blaring the speaker when you unplug the headphones, you just toggled the mute button till the LED was lit, and you knew with certainty that the speaker would be muted when you pulled the headphones. Now, in 3.19 (without software_mute=0 boot option to revert behavior to 3.18) if the LED is lit [assuming it is synched], it means only that the particular output port currently selected by pavucontrol is muted. Insert or unplug the headphones and the mute LED state may change, or it may not, depending on what the other port's mute state is. So, suppose you have headphones plugged in and they are muted, hence the mute LED is on. But the speaker may or may not be muted; the LED tells you nothing about the speaker mute state. Now, pull the headphones, and you don't know what's going to happen: The LED may turn off and the speaker may blare. Or maybe not. Confusing imo. I'm sure others disagree and prefer it the new way, but my point is not to debate which is the better behavior, but that if both the
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
At Sun, 26 Apr 2015 09:20:12 -0600,
Glenn Golden wrote:
Anyway, just my 2c, and entirely distinct from the issue at hand. Let's get
the LED working as intended first.
It's likely just a missing quirk application. There was already a
quick specific to your device (17aa:215e), but this doesn't include
the thinkpad_acpi hook.
A patch like below may fix the issue. Give it a try.
Takashi
---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 06199e4e930f..5f46bcc45995 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4879,6 +4879,8 @@ static const struct hda_fixup alc269_fixups[] = {
[ALC269_FIXUP_THINKPAD_ACPI] = {
.type = HDA_FIXUP_FUNC,
.v.func = hda_fixup_thinkpad_acpi,
+ .chained = true,
+ .chain_id = ALC269_FIXUP_SKU_IGNORE,
},
[ALC255_FIXUP_DELL1_MIC_NO_PRESENCE] = {
.type = HDA_FIXUP_PINS,
@@ -5114,11 +5116,6 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x10cf, 0x1845, Lifebook U904,
ALC269_FIXUP_LIFEBOOK_EXTMIC),
SND_PCI_QUIRK(0x144d, 0xc109, Samsung Ativ book 9 (NP900X3G),
ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x1458, 0xfa53, Gigabyte BXBT-2807,
ALC283_FIXUP_BXBT2807_MIC),
- SND_PCI_QUIRK(0x17aa, 0x20f2, Thinkpad SL410/510,
ALC269_FIXUP_SKU_IGNORE),
- SND_PCI_QUIRK(0x17aa, 0x215e, Thinkpad L512, ALC269_FIXUP_SKU_IGNORE),
- SND_PCI_QUIRK(0x17aa, 0x21b8, Thinkpad Edge 14,
ALC269_FIXUP_SKU_IGNORE),
- SND_PCI_QUIRK(0x17aa, 0x21ca, Thinkpad L412, ALC269_FIXUP_SKU_IGNORE),
- SND_PCI_QUIRK(0x17aa, 0x21e9, Thinkpad Edge 15,
ALC269_FIXUP_SKU_IGNORE),
SND_PCI_QUIRK(0x17aa, 0x21f6, Thinkpad T530,
ALC269_FIXUP_LENOVO_DOCK),
SND_PCI_QUIRK(0x17aa, 0x21fa, Thinkpad X230,
ALC269_FIXUP_LENOVO_DOCK),
SND_PCI_QUIRK(0x17aa, 0x21f3, Thinkpad T430,
ALC269_FIXUP_LENOVO_DOCK),
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
Takashi Iwai ti...@suse.de [2015-04-26 18:05:51 +0200]: At Sun, 26 Apr 2015 09:20:12 -0600, Glenn Golden wrote: Anyway, just my 2c, and entirely distinct from the issue at hand. Let's get the LED working as intended first. It's likely just a missing quirk application. There was already a quick specific to your device (17aa:215e), but this doesn't include the thinkpad_acpi hook. A patch like below may fix the issue. Give it a try. No joy, alas. Behavior unchanged from Arch 3.19.3-3 kernel. I should mention that the patch was applied against 3.19.3 sources, not the git head, but it applied without error, so assume it was ok to do that. If not, let me know. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
2015-04-27 0:05 GMT+08:00 Takashi Iwai ti...@suse.de: At Sun, 26 Apr 2015 09:20:12 -0600, Glenn Golden wrote: Anyway, just my 2c, and entirely distinct from the issue at hand. Let's get the LED working as intended first. It's likely just a missing quirk application. There was already a quick specific to your device (17aa:215e), but this doesn't include the thinkpad_acpi hook. A patch like below may fix the issue. Give it a try. Seem Thinkpad T510 has Conexant codec instead of realtek !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1b.0 0403: 8086:3b56 (rev 06) Subsystem: 17aa:215e Codec: Conexant CX20585 Address: 0 AFG Function Id: 0x1 (unsol 1) MFG Function Id: 0x2 (unsol 1) Vendor Id: 0x14f15069 Subsystem Id: 0x17aa218b Revision Id: 0x100302 https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/patch_conexant.c?id=d70f363222ef373c2037412f09a600357cfa1c7a Seem T410 and T510 have same PCI SSID but different Codec SSID ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
in response to the event. What action can be taken to turn on the mute LED? Issue an amixer/pactl/pacmd command to toggle the Master Playback mute state? Speaking as the thinkpad-acpi driver maintainer: Keeping the ThinkPad MUTE LED states in sync is the kernel's job. This is the beginning and the end of it. It clearly is not working properly right now. Possibly the defect is restricted to some thinkpads: Lenovo changes firmware behaviour sometimes. They're good about leaving a knob you can set to get whatever behaviour you want/need. They're not always that good about _testing_ it, though. And we (kernel side) are not that good at either knowing the behaviour exists, or making use of it. Or it might be a simple driver bug that affects every thinkpad with a mute LED. I hope so, because that's much easier to fix. Those are the facts. It doesn't look like there is anything pulse-audio related in this issue: it is a matter for the kernel to fix. Either in the ALSA sublayer, if it is not being able to correctly signal thinkpad-acpi to change Mute LED state, or in thinkpad-acpi if it is not correctly relaying to the thinkpar firmware the desired mute LED state. No, that won't do it, because the LED isn't following the mixer mute state (see earlier posts in this thread). Directly access the LED via some exposed interface to it? No sign that any such any such interface is available in /proc/acpi or /sys/class/leds (see comment #15 in the kernel bugtracker). And it is not going to be made available (in some thinkpads, it cannot even be done: when you change the hardware mute gate state, the EC updates the LED state to match). This is why we will consider any mute led misbehavior to be a kernel issue, to be fixed in the kernel. As I mentioned on the kernel bugtracker, I'm going to take this up with the thinkpad ACPI folks, see if they have any suggestions. I lack the hardware to develop-and-test a fix (I am long overdue for a replacement thinkpad, really. I only have a good T43, and a damaged R60), but I am open to help (and ACK kernel-side patches). -- http://support.lenovo.com/us/en/documents/migr-58317 T43 seem using snd-intel8x0 AC97 codec AD1981B https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/thinkpad_helper.c?id=b317b032d2dcb5e518cc9630cc6f1c7c24afedfc The mute led and mic led only supported by those HDA codecs (Realtek and Connexant) which use hda/thinkpad_helper.c https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/log/sound/pci/hda/patch_analog.c?qt=grepq=thinkpad Those thinkpads using ADI HDA codecs are not affected by the above patch http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=420f9739a62cdb027f5580d25c813501ff93aa6f as tpacpi_led_set is always exported by thinkpad-acpi, only thinkpad_acpi module know whether ssms interface is available or not http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=9a417ec0c9d1f7af5394333411fc4d98adb8761b Should thinkpad_acpi only disable EC console only when either SSMS or MMTS is available ? ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
Raymond Yau superquad.vort...@gmail.com [2015-04-20 11:10:32 +0800]: Refer to http://www.spinics.net/lists/ibm-acpi-devel/msg03404.html That post has been pointed out several times. I read it before my initial posting of this thread. Certainly I may have missed something, but it seems to me that it contains nothing of relevance to this issue, other than confirming that the kernel is not doing what it's supposed to be doing with the mute LED vis a vis the Master Playback mute control. (At least, it isn't doing it on my T-510). Excerpt from the above: Starting with 3.19, the default behavior is to ask the embedded controller to disable all the magic. The kernel will keep the mute ^ LED in sync with the software control, the hardware switch is disabled ^ entirely, and the mute button is just a button. The underlined sentence is exactly what is not happening on my T-510, and _that_ is the issue. The kernel (hda driver I assume they mean, but not sure) isn't keeping the mute LED in synch with the software (i.e. mixer) Master Playback mute state. That's why this would seem to be a kernel/driver bug, just as David H and Hui Wang mentioned in the initial responses to this thread. Since there also seems to be no direct access to the LED from userspace -- see earlier messages here and comment #15 on the kernel bugtracker explaining what has already been tried in that regard -- and the kernel/driver is not automatically keeping it in synch with the mixer Playback Master, it stays off. This mean the function of mute key is disabled by default Yes, but that's well known, and has already been commented on several times. In 3.19 the mute key is a soft key. If the user doesn't field the event, it does nothing, that's true. But afaict, it is also entirely irrelevant to the problem being reported. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=9a417ec0c9d1f7af5394333411fc4d98adb8761b Speaker still follow pin sense of hp and dock hp of hda codec when auto mute mode is enabled So what? What relation does that have with the mute LED not following the mixer's Master Playback mute state? I don't see any. If you do, please be explicit about it. You need to find out how to listen mute key event You need to pay attention to what's already been posted. :) I do sincerely appreciate your responsiveness on this issue, you've taken a lot of your time to look into it. But it seems like you're kind of running open loop. Listening for the mute key event is simple to do, and it's already been explained several times why this is not directly relevant to the issue being reported: Fielding the mute key event isn't, by itself, going to magically have any effect on the mute LED state. One has to take some action in response to the event. What action can be taken to turn on the mute LED? Issue an amixer/pactl/pacmd command to toggle the Master Playback mute state? No, that won't do it, because the LED isn't following the mixer mute state (see earlier posts in this thread). Directly access the LED via some exposed interface to it? No sign that any such any such interface is available in /proc/acpi or /sys/class/leds (see comment #15 in the kernel bugtracker). As I mentioned on the kernel bugtracker, I'm going to take this up with the thinkpad ACPI folks, see if they have any suggestions. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
The main thing to note is that in 3.18, when the driver fielded the mute
key events itself, it handled those events by toggling the state of a
low-level hardware-based mute switch (upper right dotted box). This HW
mute
evidently applied only to the speaker, not headphones, and seems to have
no
relationship to the pavucontrol/pactl/amixer mixer-based mute. Also --
and
central to the issue here -- invoking the HW mute function via the mute
key
also toggled the mute LED, and that LED state always faithfully reflected
the actual mute state (LED on == speaker audio off, always). In the other
direction, there was never any observed effect on the mute LED state as a
result of toggling the mixer-based Master Playback mute, via pavuconrol,
pactl, pacmd, or amixer (or in any other way that I ever found). In short,
the mute LED in 3.18 seems like it's solely under control of the mute key
event as fielded by the driver.
In 3.19, the mute key is no longer fielded directly by the driver; it
becomes
simply an ordinary userspace key. That was an intentional change and
certainly
not a bug. But the point is that in 3.19, if the user wishes to perform
muting
in userspace (e.g., by pactling the mixer mute function in response to a
mute key event, or by clicking the pavucontrol mute icon, or by issuing an
amixer or pactl command) it's not going to have the same effect that the
driver used to realize in 3.18, in two ways: One is relatively minor, and
the other is central to the issue here:
* First, and obviously, it isn't going institute the mute function via
the
HW mute, but rather via the mixer-based Master Playback mute. This in
itself is probably no big deal: There are some minor functional
differences
between the HW mute and the mixer mute, but most users won't care and
it's probably not a very important issue. Let's ignore it here.
* Second -- and here is the real issue -- since the mixer-based Master
Playback mute has (and never had, even in 3.18) any effect on the mute
LED (on my T-510) the mute LED does not follow the mixer-based mute
state. It's always off. There just doesn't seem to be any way turn on
the mute LED via pavucontrol, pactl, pacmd, or amixer.
The second item is the real head-scratcher: Not only is the functionality
of
the mute LED lost in 3.19 (on my T-510 at least) but it is David's
expectation
that the LED _ought_ to be following the Master Playback mixer mute state,
yet it does not.
Apr 16 15:56:17 ga kernel: thinkpad_acpi: ThinkPad ACPI Extras v0.25
Apr 16 15:56:17 ga kernel: thinkpad_acpi: http://ibm-acpi.sf.net/
Apr 16 15:56:17 ga kernel: thinkpad_acpi: ThinkPad BIOS 6MET81WW (1.41 ),
EC 6MHT43WW-1.18
Apr 16 15:56:17 ga kernel: thinkpad_acpi: Lenovo ThinkPad T510, model
4314DPU
Apr 16 15:56:17 ga kernel: thinkpad_acpi: detected a 16-level brightness
capable ThinkPad
Apr 16 15:56:17 ga kernel: thinkpad_acpi: radio switch found; radios are
enabled
Apr 16 15:56:17 ga kernel: thinkpad_acpi: This ThinkPad has standard ACPI
backlight brightness control, supported by the ACPI video driver
Apr 16 15:56:17 ga kernel: thinkpad_acpi: Disabling thinkpad-acpi
brightness events by default...
Apr 16 15:56:17 ga kernel: thinkpad_acpi: Standard ACPI backlight interface
available, not loading native one
Apr 16 15:56:17 ga kernel: input: ThinkPad Extra Buttons as
/devices/platform/thinkpad_acpi/input/input7
https://bugzilla.kernel.org/show_bug.cgi?id=96171
Let user know whether the mute led or mic led interface is supported by
tpacpi_led_set() when thinkpad_acpi is loaded
static int mute_led_init(struct ibm_init_struct *iibm)
{
acpi_handle temp;
int i;
for (i = 0; i TPACPI_LED_MAX; i++) {
struct tp_led_table *t = led_tables[i];
- if (ACPI_SUCCESS(acpi_get_handle(hkey_handle, t-name, temp)))
+ if (ACPI_SUCCESS(acpi_get_handle(hkey_handle, t-name, temp))) {
+pr_info(Thinkpad led %s interface supported.\n, t-name);
mute_led_on_off(t, false);
+}
else
t-state = -ENODEV;
}
return 0;
}
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
Raymond Yau superquad.vort...@gmail.com [2015-04-19 10:47:11 +0800]: You have not posted alsa-info of working 3.18 Here are alsa-info.sh reports for both kernels: http://misc.postpro.net/t510led/alsa_info_3.18.6.txt http://misc.postpro.net/t510led/alsa_info_3.19.3_soft0.txt http://misc.postpro.net/t510led/alsa_info_3.19.3_soft1.txt The difference between the 3.19 soft0 and soft1 versions is that soft0 version was booted with the kernel commandline parameter thinkpad_acpi.software_mute=0 This just reverts the muting behavior back to 3.18 (which is my preference). The soft1 version does not supply this parameter, so you get the default 3.19 behavior (i.e., software muting enabled, HW muting disabled.) Refer to alsa-info found in t510 speaker powersave regression https://lkml.org/lkml/2012/12/22/113 Superficially, to my eyes anyway, it doesn't seem related to this issue. Do you think it might be? If so, please be more explicit, I don't see the connection. Simple mixer control 'Console',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Do this console playback switch has any effect on your schematic view ? It's a read-only card, so it has no effect, but its state does reflect the HW mute state. See further below for details. AFAIK, pulseaudio ignore card 29 ThinkPadEC Yes, that seems to be right. But it can be seen via amixer -c29: Here's the observed behavior under 3.18, using the terminology from the kernel bug report: 0. Toggle MUTEKEY until MUTELED = off. 1. Start audio source, verify SPK_SOUND = on 2. 'amixer -c29 get Console' reports Mono: Playback [on] 3. Toggle MUTEKEY, verify MUTELED = on, SPK_SOUND = off 4. 'amixer -c29 get Console' reports Mono: Playback [off] That's all I see. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
You have not posted alsa-info of working 3.18 Here are alsa-info.sh reports for both kernels: http://misc.postpro.net/t510led/alsa_info_3.18.6.txt http://misc.postpro.net/t510led/alsa_info_3.19.3_soft0.txt http://misc.postpro.net/t510led/alsa_info_3.19.3_soft1.txt The difference between the 3.19 soft0 and soft1 versions is that soft0 version was booted with the kernel commandline parameter thinkpad_acpi.software_mute=0 This just reverts the muting behavior back to 3.18 (which is my preference). The soft1 version does not supply this parameter, so you get the default 3.19 behavior (i.e., software muting enabled, HW muting disabled.) Refer to alsa-info found in t510 speaker powersave regression https://lkml.org/lkml/2012/12/22/113 Superficially, to my eyes anyway, it doesn't seem related to this issue. Do you think it might be? If so, please be more explicit, I don't see the connection. Simple mixer control 'Console',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Do this console playback switch has any effect on your schematic view ? It's a read-only card, so it has no effect, but its state does reflect the HW mute state. See further below for details. AFAIK, pulseaudio ignore card 29 ThinkPadEC Yes, that seems to be right. But it can be seen via amixer -c29: Here's the observed behavior under 3.18, using the terminology from the kernel bug report: 0. Toggle MUTEKEY until MUTELED = off. 1. Start audio source, verify SPK_SOUND = on 2. 'amixer -c29 get Console' reports Mono: Playback [on] 3. Toggle MUTEKEY, verify MUTELED = on, SPK_SOUND = off 4. 'amixer -c29 get Console' reports Mono: Playback [off] That's all I see. Refer to http://www.spinics.net/lists/ibm-acpi-devel/msg03404.html Starting with 3.19, the default behavior is to ask the embedded controller to disable all the magic. The kernel will keep the mute LED in sync with the software control, the hardware switch is disabled entirely, and the mute button is just a button. This mean the function of mute key is disabled by default http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=9a417ec0c9d1f7af5394333411fc4d98adb8761b Speaker still follow pin sense of hp and dock hp of hda codec when auto mute mode is enabled Simple mixer control 'Auto-Mute Mode',0 Capabilities: enum Items: 'Disabled' 'Enabled' Item0: 'Enabled' You need to find out how to listen mute key event ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
[NOTE: This is an edited/expanded version of a previous post which never made
it to the list because it had an attachment that was too big.]
David Henningsson david.hennings...@canonical.com [2015-04-14 13:32:42 +0200]:
Just to check - you did press F4 or F5 to make all capture controls show up,
right?
Yes. I also widened out the display to make sure there were no more controls
hidden on either side.
In case it may be of interest to anyone with the same or similar issue,
here is a behavioral schematic that seems to accurately reflect the
relationship between {pavucontrol/pactl/pacmd/amixer} mute and the hardware
mute function and LEDs on my T-510, showing the differences across the
kernel change between 3.18 and 3.19:
http://misc.postpro.net/t510led/schematic_view.jpg
(The diagram isn't intended to reflect actual circuit topology, of which
I have no knowledge; only that it seems to schematically capture the observed
muting (and mute LED) behavior.)
The main thing to note is that in 3.18, when the driver fielded the mute
key events itself, it handled those events by toggling the state of a
low-level hardware-based mute switch (upper right dotted box). This HW mute
evidently applied only to the speaker, not headphones, and seems to have no
relationship to the pavucontrol/pactl/amixer mixer-based mute. Also -- and
central to the issue here -- invoking the HW mute function via the mute key
also toggled the mute LED, and that LED state always faithfully reflected
the actual mute state (LED on == speaker audio off, always). In the other
direction, there was never any observed effect on the mute LED state as a
result of toggling the mixer-based Master Playback mute, via pavuconrol,
pactl, pacmd, or amixer (or in any other way that I ever found). In short,
the mute LED in 3.18 seems like it's solely under control of the mute key
event as fielded by the driver.
In 3.19, the mute key is no longer fielded directly by the driver; it becomes
simply an ordinary userspace key. That was an intentional change and certainly
not a bug. But the point is that in 3.19, if the user wishes to perform muting
in userspace (e.g., by pactling the mixer mute function in response to a
mute key event, or by clicking the pavucontrol mute icon, or by issuing an
amixer or pactl command) it's not going to have the same effect that the
driver used to realize in 3.18, in two ways: One is relatively minor, and
the other is central to the issue here:
* First, and obviously, it isn't going institute the mute function via the
HW mute, but rather via the mixer-based Master Playback mute. This in
itself is probably no big deal: There are some minor functional differences
between the HW mute and the mixer mute, but most users won't care and
it's probably not a very important issue. Let's ignore it here.
* Second -- and here is the real issue -- since the mixer-based Master
Playback mute has (and never had, even in 3.18) any effect on the mute
LED (on my T-510) the mute LED does not follow the mixer-based mute
state. It's always off. There just doesn't seem to be any way turn on
the mute LED via pavucontrol, pactl, pacmd, or amixer.
The second item is the real head-scratcher: Not only is the functionality of
the mute LED lost in 3.19 (on my T-510 at least) but it is David's expectation
that the LED _ought_ to be following the Master Playback mixer mute state,
yet it does not.
Hope this helps to understand the issue better.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
In case it may be of interest to anyone with the same or similar issue,
here is a behavioral schematic that seems to accurately reflect the
relationship between {pavucontrol/pactl/pacmd/amixer} mute and the
hardware
mute function and LEDs on my T-510, showing the differences across the
kernel change between 3.18 and 3.19:
http://misc.postpro.net/t510led/schematic_view.jpg
(
You have not posted alsa-info of working 3.18
Refer to alsa-info found in t510 speaker powersave regression
https://lkml.org/lkml/2012/12/22/113
!!---Mixer controls for card 29 [ThinkPadEC]
Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw
6MHT46WW-1.21'
Mixer name : 'ThinkPad EC 6MHT46WW-1.21'
Components : ''
Controls : 1
Simple ctrls : 1
Simple mixer control 'Console',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [on]
Do this console playback switch has any effect on your schematic view ?
Soundcards recognised by ALSA
!!-
0 [MID]: HDA-Intel - HDA Intel MID
HDA Intel MID at 0xf262 irq 45
29 [ThinkPadEC ]: ThinkPad EC - ThinkPad Console Audio Control
ThinkPad Console Audio Control at EC reg 0x30, fw
6MHT46WW-1.21
AFAIK, pulseaudio ignore card 29 ThinkPadEC
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules?id=078a39af886ea3bb590595b973343af77c2837fe
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness]
David Henningsson david.hennings...@canonical.com [2015-04-14 13:32:42 +0200]:
Just to check - you did press F4 or F5 to make all capture controls show up,
right?
Yes. And I widened out the display to make sure there were no more controls
hidden on either side.
Btw, just in case it may be of interest to you or anyone else with the same
or similar issue: Attached is a behavioral schematic that seems to accurately
reflect the relationship between {pavucontrol/pactl} mute and the hardware
mute function and LEDs on my T-510, showing the differences across the kernel
change between 3.18 and 3.19.
The main thing to note is that in 3.18 (when the driver fielded the mute
key events itself) it appears to have handled those events by instituting
some sort of outboard speaker-only mute, completely independent of the
pavucontrol/pactl mute. In 3.19 of course, the mute key is not fielded
directly by the driver any longer, it's only a userspace key. But the point
is that if the user tries to handle the key event by pactling the mute
function, it's not going to have the same effect that the driver was able
to realize by doing whatever it did with that outboard control (including
toggling the mute LED).
(Btw, not suggesting this diagram in any way reflects the actual circuit
topology, of which I have no knowledge; only that it seems to capture the
observed muting (and mute LED) behavior.)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
David Henningsson david.hennings...@canonical.com [2015-04-15 07:14:59 +0200]: On 2015-03-30 23:54, Glenn Golden wrote: HW: ThinkPad T-510, x86_64 SW: Arch Linux (synched within a week) kernel = 3.19.2, PA 6.0 I think I found the offending commit [1]: commit 9a417ec0c9d1f7af5394333411fc4d98adb8761b Author: Andy Lutomirski l...@mit.edu Date: Fri Oct 17 17:04:29 2014 -0700 thinkpad-acpi: Try to use full software mute control It was added between 3.18 and 3.19 and concerns mute keys on Thinkpads. TTBOMU, this commit is not the source of the problem, although it is indirectly related to it. I was aware of this 3.18 - 3.19 key handling change when I filed the original post here. Raymond also called this out earlier in the thread here. Please see the background section of the detailed report referred to in Comment #3 here https://bugzilla.kernel.org/show_bug.cgi?id=96171 It explains in detail the relationship between that commit and the LED issue, and explains exactly what the bug is and what the bug isn't. The bug _isn't_ that the mute key handling was changed from driver fielded to user-fielded. That was intentional and not a bug in an of itself. The bug -- or more correctly, one of the two sub-bugs -- _is_ that the hardware-based speaker-only mute _action_ that was being taken by the driver in 3.18 (in response to an AudioMute keypress) is distinct from the pavucontrol/pactl mixer-based mute action. And it is that other action (the hardware speaker-only mute action) that (in 3.18) was also associated with the LED toggling. That hardware action (and associated LED toggling) is evidently not available via pavucontrol/pactl mute (and was even not available via pavucontrol/pactl mute even in 3.18) Knowing the answer to this, I can post a more informative ticket to the kernel guys. (Or maybe the fix is even in pulseaudio itself?) Maybe you could also try one of the thinkpad-acpi mailinglists [2]. I looked at the TP ACPI Wiki and some of the posts on the list before posting this thread. Nothing I saw there seemed to cover the specific situation regarding the AudioMute LED. The stuff that I came across there just discusses the need to add events handlers for the AudioMute and MicMute buttons, since they're no longer handled by the driver, starting with 3.19. This was was well known to me. Again, the report has all the gory details. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
Follow-on question for David H: I'm in the process of preparing a detailed writeup on this issue for Raymond over on the kernel bugtracker (ticket #96171). There are a lot of moving parts to it, and I want to make sure the details are stated correctly there to avoid unintentionally sending Raymond on a wild goose chase. So I want to ask your indulgence in clarifying one small point on something you mentioned earlier, to make certain that I have a clear understanding: [T]he mute LED reflects the state of the Master Playback Switch. Any discrepancy of the above would be a kernel bug. The attached screenshot shows how I experimented with this, and what was observed: Regardless of which output Port (speaker or headphone) is selected on pavucontrol, the ALSA Master Playback mute state indicator (MM or OO) follows the mute state shown on pavucontrol: When the pavucontrol mute icon is toggled, the MM/OO mute indicator on the ALSA Master Playback also toggles accordingly. However, the mute LED always remains off. (And all of the above also holds if pactl set-sink-mute 0 toggle is substituted for clicking the pavucontrol mute icon.) So the question is: Is the state of Master Playback Switch that you referred to in your response above indeed represented by the MM/OO display on the ALSA Master Playback slider, as I've assumed? If so, then it seems like this is clear-cut evidence that the mute LED is not behaving as expected. Thanks! ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
On 2015-03-30 23:54, Glenn Golden wrote: HW: ThinkPad T-510, x86_64 SW: Arch Linux (synched within a week) kernel = 3.19.2, PA 6.0 I think I found the offending commit [1]: commit 9a417ec0c9d1f7af5394333411fc4d98adb8761b Author: Andy Lutomirski l...@mit.edu Date: Fri Oct 17 17:04:29 2014 -0700 thinkpad-acpi: Try to use full software mute control It was added between 3.18 and 3.19 and concerns mute keys on Thinkpads. Knowing the answer to this, I can post a more informative ticket to the kernel guys. (Or maybe the fix is even in pulseaudio itself?) Maybe you could also try one of the thinkpad-acpi mailinglists [2]. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=9a417ec0c9d1f7af5394333411fc4d98adb8761b [2] http://www.thinkwiki.org/wiki/Mailinglists ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
On 2015-04-13 22:50, Glenn Golden wrote: So the question is: Is the state of Master Playback Switch that you referred to in your response above indeed represented by the MM/OO display on the ALSA Master Playback slider, as I've assumed? Your screenshot shows a virtual PulseAudio control. Try pressing F6 to select the real sound card, or start alsamixer with the -c 0 switch (or -c 1, in case -c 0 is a HDMI card). Otherwise, you're correct. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
Raymond Yau superquad.vort...@gmail.com [2015-04-05 09:47:36 +0800]: HW: ThinkPad T-510, x86_64 SW: Arch Linux (synched within a week) kernel = 3.19.2, PA 6.0 On the above setup, the mic mute function (invoked via pavucontrol) works as expected: Click the mute icon, it mutes the mic input, indicates the muted state by greying out the pavucontrol mic gain control, and illuminates the little LED on the mic mute button. But the analogous functionality for muting audio output only does the first two things, and has no effect on the mute LED. (The LED is always off.) From googling around, I'm pretty sure that these two particular LEDs are not directly under user control (e.g. via ACPI) but are somehow bound to the mute/unmute functionality in the snd-hda-intel driver. This understanding is based on kernel posts like this: https://bugzilla.kernel.org/show_bug.cgi?id=49391 and other similar ones. The above report seem has no relationship with your problem, the laoptop has dual headphone jacks, four speakers and subwoofers I didn't say that report (or the laptop it pertains to) had anything directly to do with the problem being reported here. All I said was that post (and others similar) led me to believe -- see comments #7, #8, and #11 there -- that the mute LEDs are probably controlled by the snd-hda-intel driver itself, rather than under userspace control. That in turn suggested that the problem was most likely a kernel driver issue and unrelated to pulseaudio. I was asking the question here just to verify that understanding before filing a kernel bug report. Based on the follow-on comments here by Hui and David, it seems that understanding was correct; it is a kernel issue, so I filed a report on LKML. https://bugs.launchpad.net/ubuntu/+source/udev/+bug/408903 If your mic mute generate keypress event and key release event, you need pulseaudio also listen to those event to update the status of mic mute icon in pavucontrol The problem I reported is not related in any way to keypress events of the mute keys (or any others). It is only concerned with the audio mute and mic mute indicator LEDs. As I said early in the post, I was toggling the mute functionality not via the mute keys, but via pavucontrol itself. The functionality of both types of mute operation was confirmed: Toggling the output mute control via pavucontrol indeed toggled the audio output signal, and togglng the mic mute control likewise toggled the mic input signal. And both flavors of muting were accompanied by the expected greying-out of the associated pavucontrol sliders. The problem is that the audio output mute _LED_ does not toggle with the output mute state of the driver. (The mic mute LED does toggle with the mic input mute state.) I'm aware that in 3.19 kernel, the audio output mute and mic mute keys were changed from direct driver control of the mute function to ordinary softkeys, which are under userspace control; I think this might be what you were getting at in your comment above. But this has nothing to do with the reported issue. Hope this helps to understand. Thanks for your time in replying in any case. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
HW: ThinkPad T-510, x86_64 SW: Arch Linux (synched within a week) kernel = 3.19.2, PA 6.0 On the above setup, the mic mute function (invoked via pavucontrol) works as expected: Click the mute icon, it mutes the mic input, indicates the muted state by greying out the pavucontrol mic gain control, and illuminates the little LED on the mic mute button. But the analogous functionality for muting audio output only does the first two things, and has no effect on the mute LED. (The LED is always off.) From googling around, I'm pretty sure that these two particular LEDs are not directly under user control (e.g. via ACPI) but are somehow bound to the mute/unmute functionality in the snd-hda-intel driver. This understanding is based on kernel posts like this: https://bugzilla.kernel.org/show_bug.cgi?id=49391 The above report seem has no relationship with your problem, the laoptop has dual headphone jacks, four speakers and subwoofers and other similar ones. Before filing a ticket with the kernel guys, wanted to ask if this function-LED binding is in any way under control of pulseaudio itself? In other words, I guess what I'm asking is whether pulseaudio just tells the driver to mute the audio, and the driver sets the LED state accordingly, or whether pulse tells the driver separately to mute the audio and also turn on the LED. Knowing the answer to this, I can post a more informative ticket to the kernel guys. (Or maybe the fix is even in pulseaudio itself?) https://bugs.launchpad.net/ubuntu/+source/udev/+bug/408903 If your mic mute generate keypress event and key release event, you need pulseaudio also listen to those event to update the status of mic mute icon in pavucontrol https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=b317b032d2dcb5e518cc9630cc6f1c7c24afedfc ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
David Henningsson david.hennings...@canonical.com [2015-03-31 08:43:04 +0200]: On 2015-03-31 05:51, Hui Wang wrote: According to my understanding, it should be the former one, PA tells the driver to mute the audio, and the driver sets the LED accordingly. Yes, this is correct. More specific, the mic mute LED reflects the state of the Capture Switch mixer control (mic mute LED lit when Capture Switch is off), and the mute LED reflects the state of the Master Playback Switch (mute LED lit when Master Playback Switch is off). Any discrepancy of the above would be a kernel bug. Ok, thanks guys! fyi: kernel.org ML report filed here: http://marc.info/?l=linux-kernelm=142801293803024 - Glenn ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
On 2015-03-31 05:51, Hui Wang wrote: On 03/31/2015 05:54 AM, Glenn Golden wrote: HW: ThinkPad T-510, x86_64 SW: Arch Linux (synched within a week) kernel = 3.19.2, PA 6.0 On the above setup, the mic mute function (invoked via pavucontrol) works as expected: Click the mute icon, it mutes the mic input, indicates the muted state by greying out the pavucontrol mic gain control, and illuminates the little LED on the mic mute button. But the analogous functionality for muting audio output only does the first two things, and has no effect on the mute LED. (The LED is always off.) From googling around, I'm pretty sure that these two particular LEDs are not directly under user control (e.g. via ACPI) but are somehow bound to the mute/unmute functionality in the snd-hda-intel driver. This understanding is based on kernel posts like this: https://bugzilla.kernel.org/show_bug.cgi?id=49391 and other similar ones. Before filing a ticket with the kernel guys, wanted to ask if this function-LED binding is in any way under control of pulseaudio itself? In other words, I guess what I'm asking is whether pulseaudio just tells the driver to mute the audio, and the driver sets the LED state accordingly, or whether pulse tells the driver separately to mute the audio and also turn on the LED. According to my understanding, it should be the former one, PA tells the driver to mute the audio, and the driver sets the LED accordingly. Yes, this is correct. More specific, the mic mute LED reflects the state of the Capture Switch mixer control (mic mute LED lit when Capture Switch is off), and the mute LED reflects the state of the Master Playback Switch (mute LED lit when Master Playback Switch is off). Any discrepancy of the above would be a kernel bug. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness
On 03/31/2015 05:54 AM, Glenn Golden wrote: HW: ThinkPad T-510, x86_64 SW: Arch Linux (synched within a week) kernel = 3.19.2, PA 6.0 On the above setup, the mic mute function (invoked via pavucontrol) works as expected: Click the mute icon, it mutes the mic input, indicates the muted state by greying out the pavucontrol mic gain control, and illuminates the little LED on the mic mute button. But the analogous functionality for muting audio output only does the first two things, and has no effect on the mute LED. (The LED is always off.) From googling around, I'm pretty sure that these two particular LEDs are not directly under user control (e.g. via ACPI) but are somehow bound to the mute/unmute functionality in the snd-hda-intel driver. This understanding is based on kernel posts like this: https://bugzilla.kernel.org/show_bug.cgi?id=49391 and other similar ones. Before filing a ticket with the kernel guys, wanted to ask if this function-LED binding is in any way under control of pulseaudio itself? In other words, I guess what I'm asking is whether pulseaudio just tells the driver to mute the audio, and the driver sets the LED state accordingly, or whether pulse tells the driver separately to mute the audio and also turn on the LED. According to my understanding, it should be the former one, PA tells the driver to mute the audio, and the driver sets the LED accordingly. Knowing the answer to this, I can post a more informative ticket to the kernel guys. (Or maybe the fix is even in pulseaudio itself?) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
