Re: [pulseaudio-discuss] Strange parsing module args?

[Colin Guthrie]

'Twas brillig, and mar...@saepia.net at 21/05/11 16:14 did gyre and gimble:
 why following command does not work
 
 load-module module-null-sink sink_description=tuned\ patchbay:\ TCP\
 source\ xxx,sink_name=tuned.patchbay.source.xxx
 
 
 while this one works:
 
 load-module module-null-sink
 sink_name=tuned.patchbay.source.xxx,sink_description=tuned\
 patchbay:\ TCP\ source\ xxx
 
 
 Why argument order makes difference? Is it correct behaviour or a bug?

Neither are correct!

The arguments should be separated by spaces, not commas and the argument
for sink_description is actually description (although even this is
deprecated as you should now use the more generic sink_properties
argument with a device.description= entry.

In the second example above, by using a comma, you're actually just
giving your sink a crazy name without any description at all!


e.g. both:
load-module module-null-sink description=tuned\ patchbay:\ TCP\ source\
xxx sink_name=tuned.patchbay.source.xxx

 and

load-module module-null-sink sink_name=tuned.patchbay.source.xxx
description=tuned\ patchbay:\ TCP\ source\ xxx

both work fine.


But a better way of doing it would be:

pactl load-module module-null-sink sink_name=tuned.patchbay.source.xxx
sink_properties=\device.description=\\\tuned patchbay: TCP source
xxx

(note that as I passed this ivia the command line, I had to double
escape the escaping!) It would be slightly less nasty looking if it was
in the startup script (i.e. default.pa or system.pa)

HTHs

Col






-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] How to redirect pulse audio through ssh?

[Quinn Plattel]

Hi,

I tried the pulse cookie method.  Here is what I did:

- on the local sound server side, I copied ~/.pulse-cookie to the remote
sound client to /etc/pulse/pulse-cookie-n900
- on the remote sound client side, I added the following two lines to
/etc/pulse/client.conf:
  default-server = localhost
  cookie-file = /etc/pulse/pulse-cookie-n900
- on the remote sound client side, I made /etc/pulse/pulse-cookie-n900
permissions 644
- on the local sound server side, I did a ssh -X -R 4713:localhost:4713
remote-sound-client PULSE_LOG=99 pactl stat
The following output of pactl stat follows:
--
Using shared memory pool with 1024 slots of size 64.0 KiB each, total size
is 64.0 MiB, maximum usable slot size is 65472
Trying to connect to localhost:4713...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: no
Connection failure: Connection terminated
--

and pulseaudio daemon reports protocol error, kicking client

So no luck with cookies either.  I could try and upgrade pulseaudio on the
local server side, but it is going to be tricky.

br,
Quinn

On Mon, May 23, 2011 at 10:29 AM, Colin Guthrie gm...@colin.guthr.iewrote:

 'Twas brillig, and Quinn Plattel at 23/05/11 05:52 did gyre and gimble:
  HI.
 
  Last post on this thread, then I will start a new one.
  I managed to cut down the delay considerably by simplifying the commands:
 
  local sound server: ssh -L 5901:localhost 5901 -L 1234:localhost:1234
  remote sound client *parec | nc -l 1234
  local sound server: nc localhost 1234 | pacat
 
  The advantage with this is that the volume can be controlled manually
  with the local sound server's volume control and the delay is cut down
  to 3-5 seconds.


 The commands and procedure I outlined before is working fine and is free
 from bizarre work arounds. I'm not sure if the protocol error you are
 getting is coming form a bug in the client side or the server side, but
 either way it can be easily fixed if it's debugged appropriately.

 The lack of a cookie can be solved in several ways (e.g. by copying the
 ~/.pulse_cookie file between machines, or by setting up anonymous
 authentication when loading the TCP protocol module).

 I don't think your workaround (while creative) is the right way to go.
 Far a start parec|pacat has no dynamic sample rate adjustments to
 compensate for different clocks.

 Also with the parec command it seems you are connecting to to the remote
 PA daemon and recording from a monitor source (assuming no real source
 exists on the machine, the monitor source would be the default) so as to
 capture the sound which you then play back via pacat on the local
 system. If that's the case then you're already talking to the wrong PA
 daemon. As I said in my previous mail any client that runs on the remote
 system should connect *directly* (via SSH tunnel) to the remote PA. I'm
 sure it wouldn't take too long to work out the incompatibilities between
 the two protocol versions, but perhaps the one in Maemo has some kind of
 customisation applied on top that makes it generally incompatible?

 In general the protocol is backwards compatible and while I'd have to
 look, I'm not aware of any specific incompatibilities between 0.9.21 and
 0.9.15


 But if you cannot work out the protocol error here, I guess you're work
 around is the easiest option :s

 Col



 --

 Colin Guthrie
 gmane(at)colin.guthr.ie
 http://colin.guthr.ie/

 Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
 Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss




-- 
Best regards/Med venlig hilsen,
Quinn Plattel
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] How to change profile of bluetooth headset for different applications?

[Lin, Mengdong]

Is it possible to handle bluetooth profile change within 
module-bluetooth-device, instead of unload this module and reloading it with 
the new profile argument for the same device?

I need my bluetooth headset working under A2DP profile for a music/video 
application and switch to HSP profile automatically for a incoming phone 
application. I wonder if the module-bluetooth-device can monitor application 
change by hooking sink input's put and unlink event, change profile 
accordingly, and create/delete sink or source by itself. Then 
module-switch-on-connect can handle sink/source switch and 
module-cork-music-on-phone can handle music interrupted by a incoming call :)

My current solution is to monitor application change in 
module-bluetooth-discover: when a phone's input stream is put and current 
profile is not HSP, the discover module will unload module-bluetooth-device 
and reload it to HSP profile. I wonder if the bluetooth device module can 
handle this by itself so unloading and reloading can be saved.

I have another question, I learned that the internal concept of a single 
default device can be replaced by priority lists of devices in future routing 
(from Colin's blog: http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/)
Can the logic of module-switch-on-connect conflict with the new routing 
design?
If yes, this means a latest connected Bluetooth headset may not be the default 
device for a phone call and changing the profile is not needed. How can the 
Bluetooth device module know whether it's the default device for an application 
when this application's input stream is PUT?

Thanks
Amanda
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] How to debug a protocol error message?

[Quinn Plattel]

Hi,

I am currently having problems with communication between a version 0.9.22
pulseaudio client and a version 0.9.15 pulseaudio server.
Here are the steps to reproduce the error message:
pulseaudio server side: ssh -X -R 4713:localhost:4713
remote-pulseaudio-client PULSE_SERVER=localhost:4713 pactl stat

client reports:

Using shared memory pool with 1024 slots of size 64.0 KiB each, total size
is 64.0 MiB, maximum usable slot size is 65472
Trying to connect to localhost:4713...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: no
Connection failure: Connection terminated
-

server reports:
--
protocol error, kicking client
--

I have done some testing and a 0.9.15 server has no problems communicating
with a 0.9.14 client, but
a 0.9.15 server has this error when communicating with a 0.9.19 or 0.9.22
client.

Where do I begin to debug this error?

-- 
Best regards/Med venlig hilsen,
Quinn Plattel
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] How to change profile of bluetooth headset for different applications?

[Colin Guthrie]

'Twas brillig, and Lin, Mengdong at 23/05/11 16:58 did gyre and gimble:
 Is it possible to handle bluetooth profile change within
 “module-bluetooth-device”, instead of unload this module and reloading
 it with the new profile argument for the same device?

Yeah, this can be changed quite easily. It's already exposed in the API
to allow profile changes without reloading the module.


 I need my bluetooth headset working under A2DP profile for a music/video
 application and switch to HSP profile automatically for a incoming phone
 application. I wonder if the “module-bluetooth-device” can monitor
 application change by hooking sink input’s put and unlink event, change
 profile accordingly, and create/delete sink or source by itself. Then
 “module-switch-on-connect” can handle sink/source switch and
 “module-cork-music-on-phone” can handle music interrupted by a incoming
 call J

Yeah, this kind of support is already planned, so it's certainly not
beyond the realms of possibility!  The policy based configuration goes
beyond bluetooth, for example, if we play 5.1 input, perhaps we should
change to a 5.1 profile (this is a rather basic example, but when UCM
support comes in, this kind of thing will be somewhat commonplace)


 My current solution is to monitor application change in
 “module-bluetooth-discover”: when a phone’s input stream is put and
 current profile is not HSP, the discover module will unload
 “module-bluetooth-device” and reload it to HSP profile. I wonder if the
 bluetooth device module can handle this by itself so unloading and
 reloading can be saved.

Yes, you can just change the profile (pa_card_set_profile()). The sink
itself should ultimately disappear and reappear which may fire other
hooks etc, but hopefully that won't get in your way.

I'm not 100% sure where this code should go however... I'm not convinced
it should be in module-bluetooth-device


How about this:

Define a new card property similar in concept to
PA_PROP_DEVICE_INTENDED_ROLES (device.intended_roles) called
PA_PROP_DEVICE_INTENDED_PROFILE (device.intended_profile).

In bluetooth device, when loading a headset that has both HSP and A2DP,
populate the device with the following code:

if (supports_hsp  supports_a2dp)
{
  char *k;

  k = pa_sprintf_malloc(%s.%s, PA_PROP_DEVICE_INTENDED_PROFILE, music);
  pa_proplist_sets(card_data.proplist, k, a2dp);
  pa_xfree(k);

  k = pa_sprintf_malloc(%s.%s, PA_PROP_DEVICE_INTENDED_PROFILE, video);
  pa_proplist_sets(card_data.proplist, k, a2dp);
  pa_xfree(k);

  k = pa_sprintf_malloc(%s.%s, PA_PROP_DEVICE_INTENDED_PROFILE, phone);
  pa_proplist_sets(card_data.proplist, k, hsp);
  pa_xfree(k);
}

This should result in pacmd list-cards dumping a proplist that includes:

 device.intended_profile.music = a2dp
 device.intended_profile.video = a2dp
 device.intended_profile.phone = hsp



Then a separate module (module-intended-profiles?) could take care of
listening quite generically for streams landing on sink and do the
following logic:


if (!si-sink || !si-sink-card)
return PA_HOOK_OK;

char *role = pa_proplist_gets(si-proplist, PA_PROP_MEDIA_ROLE);
if (!role)
return PA_HOOK_OK;

char *k = pa_sprintf_malloc(%s.%s, PA_PROP_DEVICE_INTENDED_PROFILE, role);
pa_card *card = si-sink-card;
char *profile = pa_proplist_gets(card-proplist, k);
pa_xfree(k);
if (!profile)
return PA_HOOK_OK;

if (!pa_streq(card-active_profile, profile)) {
   /* Save the current profile for later restoration */
   ...

   if (pa_card_set_profile(card, profile, FALSE)  0)
   /* Find the sink of this card as the above call will likely have
changed it */
   sink = pa_idxset_first(card-sinks, NULL);

   pa_sink_input_move_to(si, sink, FALSE);
}


This code is then completely generic. I'm not 100% sure how well this
will work in practice as there may be some nasty races etc. but I think
this general approach could work... Perhaps others (i.e. Tanu :D) have
better suggestions?


 I have another question, I learned that the internal concept of a single
 default device can be replaced by priority lists of devices in future
 routing (from Colin’s blog:
 http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/)
 
 Can the logic of “module-switch-on-connect” conflict with the new
 routing design?

Yes and in fact I've stated as such on
http://pulseaudio.org/ticket/706#comment:11 although I will obviously
ensure that any functionality it achieves is preserved when implementing
more advanced routing options :)


 If yes, this means a latest connected Bluetooth headset may not be the
 default device for a phone call and changing the profile is not needed.
 How can the Bluetooth device module know whether it’s the default device
 for an application when this application’s input stream is PUT?

Good question! I'm not 100% sure, but I think the approach I outlined
above (caveats with races not withstanding) could be the short term
solution.

We were recently talking about routing to sinks+ports in a 

[pulseaudio-discuss] Dealing with the ThinkPad hardware mixer

[Andrew Lutomirski]

Most ThinkPad laptops have an extra mixer that has nothing to do with
the HDA audio hardware.  The kernel can talk to it through the
embedded controller and, if it's muted, then there's no sound even if
the normal controls are all set on.

These laptops have three special buttons.  The mute button either
mutes the mixer or toggles the mute state.  The volume up button
unmutes the mixer (if muted) and sends KEY_VOLUMEUP.  The volume down
button unmutes the mixer and sends KEY_VOLUMEDOWN.

On very new models, there's a hardware mute light that indicates the
status of the hardware mute.

The thinkpad-acpi driver currently exposes an ALSA mixer and the
alsamixer utility can talk to it.  But PulseAudio ignores it
completely.

What is the kernel supposed to do to get PulseAudio to DTRT?  On some,
but not (I think) all, models, we can disable hardware mixer control
and make all of the buttons act like ordinary buttons, but that will
cause the light (if present) to malfunction, and I don't know if all
models can do this.  So as it stands, PulseAudio would have to
understand that the mixer is special and watch for ALSA change
notifications.

I'm willing to change the thinkpad-acpi driver to make it work better,
but I know nothing at all about PulseAudio internals.  What should I
do?

(There's an added complexity.  Really old models have mute and volume.
 I don't own one, so I don't know much about how they work.)

--Andy
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Dealing with the ThinkPad hardware mixer

[Colin Guthrie]

'Twas brillig, and Andrew Lutomirski at 23/05/11 18:21 did gyre and gimble:
 What is the kernel supposed to do to get PulseAudio to DTRT?  On some,
 but not (I think) all, models, we can disable hardware mixer control
 and make all of the buttons act like ordinary buttons, but that will
 cause the light (if present) to malfunction, and I don't know if all
 models can do this.  So as it stands, PulseAudio would have to
 understand that the mixer is special and watch for ALSA change
 notifications.
 
 I'm willing to change the thinkpad-acpi driver to make it work better,
 but I know nothing at all about PulseAudio internals.  What should I
 do?

Can you give some more details?

e.g. does it show up under the same alsa card as the HDA or is it separate?

amixer -c0 (or appropriate number) would be useful to begin with :)

Thanks

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Dealing with the ThinkPad hardware mixer

[Tom Gundersen]

On Mon, May 23, 2011 at 7:50 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Andrew Lutomirski at 23/05/11 18:21 did gyre and gimble:
 What is the kernel supposed to do to get PulseAudio to DTRT?  On some,
 but not (I think) all, models, we can disable hardware mixer control
 and make all of the buttons act like ordinary buttons, but that will
 cause the light (if present) to malfunction, and I don't know if all
 models can do this.  So as it stands, PulseAudio would have to
 understand that the mixer is special and watch for ALSA change
 notifications.

 I'm willing to change the thinkpad-acpi driver to make it work better,
 but I know nothing at all about PulseAudio internals.  What should I
 do?

 Can you give some more details?

 e.g. does it show up under the same alsa card as the HDA or is it separate?

 amixer -c0 (or appropriate number) would be useful to begin with :)

I have a ThinkPad X60 which I think is one of the relevant models. I
have a mute botton and two volume buttons, but no light. Pressing vol
up/down unmutes and changes the volume.

As explained by Andy,
alsamixer -c29
shows the thinkpad mixer and it works as expected (read-only).

Below are the outputs of amixer for my system (running 2.6.39 fwiw).
I'd be happy to try patches or help in any other way to make this work
nicely with PA.

Cheers,

Tom

teg@x60 ~ % amixer -c29
Simple mixer control 'Console',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 14
  Mono: Playback 10 [71%] [off]



teg@x60 ~ % amixer -c0
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 63
  Mono:
  Front Left: Playback 61 [97%] [0.00dB] [on]
  Front Right: Playback 61 [97%] [0.00dB] [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 23 [74%] [0.00dB] [on]
  Front Right: Playback 23 [74%] [0.00dB] [on]
Simple mixer control 'CD',0
  Capabilities: pvolume pswitch cswitch cswitch-joined cswitch-exclusive penum
  Capture exclusive group: 0
  Playback channels: Front Left - Front Right
  Capture channels: Mono
  Limits: Playback 0 - 31
  Mono: Capture [off]
  Front Left: Playback 23 [74%] [0.00dB] [on]
  Front Right: Playback 23 [74%] [0.00dB] [on]
Simple mixer control 'Mic',0
  Capabilities: pvolume pswitch cswitch cswitch-joined cswitch-exclusive penum
  Capture exclusive group: 0
  Playback channels: Front Left - Front Right
  Capture channels: Mono
  Limits: Playback 0 - 31
  Mono: Capture [on]
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Mic Boost',0
  Capabilities: volume penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 3
  Front Left: 1 [33%] [10.00dB]
  Front Right: 1 [33%] [10.00dB]
Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958 Default PCM',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958 Playback Source',0
  Capabilities: enum
  Items: 'PCM' 'ADC'
  Item0: 'PCM'
Simple mixer control 'Beep',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 15
  Mono: Playback 0 [0%] [-45.00dB] [off]
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 15
  Front Left: Capture 15 [100%] [22.50dB] [on]
  Front Right: Capture 15 [100%] [22.50dB] [on]
Simple mixer control 'Mix',0
  Capabilities: cswitch cswitch-joined cswitch-exclusive penum
  Capture exclusive group: 0
  Capture channels: Mono
  Mono: Capture [off]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Dealing with the ThinkPad hardware mixer

[Andrew Lutomirski]

On Mon, May 23, 2011 at 4:00 PM, Tom Gundersen t...@jklm.no wrote:
 On Mon, May 23, 2011 at 7:50 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Andrew Lutomirski at 23/05/11 18:21 did gyre and gimble:
 What is the kernel supposed to do to get PulseAudio to DTRT?  On some,
 but not (I think) all, models, we can disable hardware mixer control
 and make all of the buttons act like ordinary buttons, but that will
 cause the light (if present) to malfunction, and I don't know if all
 models can do this.  So as it stands, PulseAudio would have to
 understand that the mixer is special and watch for ALSA change
 notifications.

 I'm willing to change the thinkpad-acpi driver to make it work better,
 but I know nothing at all about PulseAudio internals.  What should I
 do?

 Can you give some more details?

 e.g. does it show up under the same alsa card as the HDA or is it separate?

 amixer -c0 (or appropriate number) would be useful to begin with :)

 I have a ThinkPad X60 which I think is one of the relevant models. I
 have a mute botton and two volume buttons, but no light. Pressing vol
 up/down unmutes and changes the volume.

 As explained by Andy,
 alsamixer -c29
 shows the thinkpad mixer and it works as expected (read-only).

 Below are the outputs of amixer for my system (running 2.6.39 fwiw).
 I'd be happy to try patches or help in any other way to make this work
 nicely with PA.

My laptop will behave identically as far as ALSA is concerned.

Tom, if you apply this patch:

http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg01884.html

then you may find that some bugs are fixed.  For example, right now I
suspect that hitting mute repeatedly will make PA toggle the software
mute on and off but will leave the mixer muted, leading to confusion
as to why there's no sound.  I also suspect that alsamixer does not
update itself when you press mute (but that if you quit and reload it
you'll see the new state).

If you're using acpi_osi=Linux then you'll see something different.

With that patch, pressing mute will not make PA do anything, which is
better than the current behavior of doing the wrong thing.  alsamixer
should also update itself automatically.  And you can play with
/sys/devices/platform/thinkpad_acpi/volume_autocontrol to change how
the button works.

I want to make PA play well with that patch or a modified version of it.

---Andy
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Dealing with the ThinkPad hardware mixer

[David Henningsson]

Hi Andrew and thanks for dealing with this issue! I'm sometimes working 
with certifying Lenovo for Canonical/Ubuntu, so this definitely concerns 
me. However I know very little about the thinkpad-acpi driver and would 
like to know more about how it works, and especially the mixer part.


On 2011-05-23 19:21, Andrew Lutomirski wrote:

Most ThinkPad laptops have an extra mixer that has nothing to do with
the HDA audio hardware.  The kernel can talk to it through the
embedded controller and, if it's muted, then there's no sound even if
the normal controls are all set on.


Does this concern the internal speaker only, or headphones / line out as 
well? Or can that differ between models? I'm assuming it doesn't mute e 
g USB headset or audio out over HDMI.



These laptops have three special buttons.  The mute button either
mutes the mixer or toggles the mute state.  The volume up button
unmutes the mixer (if muted) and sends KEY_VOLUMEUP.  The volume down
button unmutes the mixer and sends KEY_VOLUMEDOWN.

On very new models, there's a hardware mute light that indicates the
status of the hardware mute.

The thinkpad-acpi driver currently exposes an ALSA mixer and the
alsamixer utility can talk to it.  But PulseAudio ignores it
completely.

What is the kernel supposed to do to get PulseAudio to DTRT?


Seen from my perspective, and maybe along the lines of Colin's reply, I 
think the best would be to try to integrate the hw mute in the HDA card 
at the kernel level (and thus skip card 29 entirely).



On some,
but not (I think) all, models, we can disable hardware mixer control
and make all of the buttons act like ordinary buttons, but that will
cause the light (if present) to malfunction, and I don't know if all
models can do this.  So as it stands, PulseAudio would have to
understand that the mixer is special and watch for ALSA change
notifications.


So, what can the thinkpad-acpi driver do here? Can it e g control the 
hardware mute status at all, or can that only be done by pressing the keys?



I'm willing to change the thinkpad-acpi driver to make it work better,
but I know nothing at all about PulseAudio internals.  What should I
do?

(There's an added complexity.  Really old models have mute and volume.
  I don't own one, so I don't know much about how they work.)


As a maybe unrelated issue, many of these thinkpads also have a 
microphone mute hotkey I was hoping to be able to get to work at some 
point. Assuming we add a new key to linux/input.h, would it be easy for 
you to fix that in the thinkpad-acpi driver? I think it currently 
triggers KEY_UNKNOWN.



--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss