Re: [pulseaudio-discuss] Dealing with the ThinkPad hardware mixer
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
Re: [pulseaudio-discuss] Dealing with the ThinkPad hardware mixer
On Mon, May 23, 2011 at 4:00 PM, Tom Gundersen wrote: > On Mon, May 23, 2011 at 7:50 PM, Colin Guthrie 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
On Mon, May 23, 2011 at 7:50 PM, Colin Guthrie 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
'Twas brillig, and Andrew Lutomirski at 23/05/11 18:59 did gyre and gimble: > On Mon, May 23, 2011 at 1:50 PM, Colin Guthrie 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 :) > > It's separate. I can send details when I get home, but from memory: > > alsamixer -c1 sees the HDA mixers. > alsamixer -c29 sees the thinkpad-acpi mixer. > > On recent thinkpads with my pending thinkpad-acpi changes, alsamixer > -c29 will update itself when the hardware buttons change the mixer > state. Without my patches, alsamixer won't notice. Ahh, tricky! In an ideal world, it would be super awesome if the alsa user-space lib could configure the additional controls within the same card (in much the same way that it sometimes configures a PCM control for the softvol plugin), thus solving the problem below PA. If that was possible, supporting this would be rather trivial in PA. But if not, I think the solution could be related to some support that is proposed to help a different, but related problem. To give some background on that problem: When you plug a USB device in that is e.g. a headset, but also contains some volume buttons to adjust the vol. Now these buttons appear under /dev/input but in a way that doesn't really tie in to the actual sound card, so when the user presses these buttons, we don't have any way to adjust the correct sound card. At present, pressing such buttons changes the volume of the current default card, not the one it's actually physically connected to (unless it happens to be the default). So, the idea was to attach some kind of "originating device" property via udev to both the sound card and the input device. This would allow us to pair them with each other and thus the desktop environment could ultimately adjust the correct volume when it handles the volume key press events. I suspect a similar thing could be done here... i.e. somehow pair the two controls. That way we can enumerate the controls as a single entity. > The magic hardware mixer is a created by the thinkpad-acpi driver > without any attempt to associate it with any other ALSA device on the > system. I suspect that the driver should be doing something different > (and again, I'm willing to make and submit changes, but I don't know > what it should do to make PulseAudio happy). The changes needed here are rather extensive so I wouldn't expect it to happen overnight sadly. There could be some kind of hacks introduced in the mean time, but I'm not really in a position to guess at this. David and Tanu are probably in a better position, but David is on leave for a couple weeks so likely won't read this for a while The code in PA is quite flexible but it's ultimately rather complex. We have a whole bunch of mixer profiles that ultimately work out what the card is capable of. It's quite focused on applying ot a single control interface just now, and I can't think of a clean way of the top of my head to extend that, but then I don't know that code, so this is, in itself, not overly surprising :) Please do post the additional mixer details when you have them. -- 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
On Mon, May 23, 2011 at 1:50 PM, Colin Guthrie 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 :) It's separate. I can send details when I get home, but from memory: alsamixer -c1 sees the HDA mixers. alsamixer -c29 sees the thinkpad-acpi mixer. On recent thinkpads with my pending thinkpad-acpi changes, alsamixer -c29 will update itself when the hardware buttons change the mixer state. Without my patches, alsamixer won't notice. The magic hardware mixer is a created by the thinkpad-acpi driver without any attempt to associate it with any other ALSA device on the system. I suspect that the driver should be doing something different (and again, I'm willing to make and submit changes, but I don't know what it should do to make PulseAudio happy). --Andy > > 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 > ___ 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
'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
[pulseaudio-discuss] Dealing with the ThinkPad hardware mixer
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] How to change profile of bluetooth headset for different applications?
'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
solut
[pulseaudio-discuss] How to debug a "protocol error" message?
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 "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
[pulseaudio-discuss] How to change profile of bluetooth headset for different applications?
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
Re: [pulseaudio-discuss] How to redirect pulse audio through ssh?
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 "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 wrote: > '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 > > *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
Re: [pulseaudio-discuss] Strange parsing module args?
'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?
'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 > *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
