Re: [pulseaudio-discuss] How to debug a protocol error message?
2011/5/23 Quinn Plattel qie...@gmail.com: 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? The difficulty here is of course that while the server throws an error, you're looking to fix the client side, because there won't be a maintainance release of the 0.9.15 series anymore. If you can install debug symbols, you can set a breakpoint at protocol_error(). This will break in command_stat() (src/pulsecore/protocol-native.c), right after the !pa_tagstruct_eof(t) check. There you can inspect what kind of unexpected extra data is in the tagstruct and take it from there. Please also try whether other commands work. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to debug a protocol error message?
'Twas brillig, and Maarten Bosmans at 24/05/11 08:31 did gyre and gimble: 2011/5/23 Quinn Plattel qie...@gmail.com: 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? The difficulty here is of course that while the server throws an error, you're looking to fix the client side, because there won't be a maintainance release of the 0.9.15 series anymore. If you can install debug symbols, you can set a breakpoint at protocol_error(). This will break in command_stat() (src/pulsecore/protocol-native.c), right after the !pa_tagstruct_eof(t) check. There you can inspect what kind of unexpected extra data is in the tagstruct and take it from there. Please also try whether other commands work. Yup Maarten's advice is good there. But what is interesting is that our official 0.9.15 version ships with protocol 15, not 16... Your debug suggests the the remote end is protocol 16.. This suggests to me that the extensions in the Maemo version are non-standard and therefore require consultation with their lists. You should check their code to see what commits changed the protocol version to 16. It could be that they just backported the changes from our version 16 shipped in 0.9.16 (which was an API to select client side API detection) or it could be something completely custom. As I'm not familiar with their modifications, I cannot really help. 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] Why is it still hissing?
Ok, so there is still a high-pitched noise with 5.1, although I tried to fix that a while ago. I now know what the error is, but perhaps somewhat with more GCC-ASM skills can help me fix it. I spent parts of yesterday and today analysing it and came up with the following conclusion: Here's the asm code as written in svolume_sse.c, function pa_volume_s16ne_sse2: #define MOD_ADD(a,b) \ add #a, %3 \n\t /* channel += inc */ \ mov %3, %4 \n\t\ sub #b, %4 \n\t /* tmp = channel - channels */ \ cmovae %4, %3 \n\t /* if (tmp = 0) channel = tmp */ And called with: MOD_ADD($8, %5) Here's what it shows up with gdb (on i386) : 0x00f3fbe6 +550: add$0x8,%edi 0x00f3fbe9 +553: mov%edi,%ecx 0x00f3fbeb +555: sub%edi,%ecx 0x00f3fbed +557: cmovae %ecx,%edi The error: both %3 and %5 is turned into the %edi register. Here's the register allocation: : +r (samples), +r (volumes), +r (length), =D (channel), =r (temp) : rm ((pa_reg_x86)channels) : cc As I can tell from the above the =D forces %3 to go into %edi, but I don't know how to tell GCC not to use %edi for %5 (channels) as well, does anybody know? Can this be a GCC bug? (Btw, based on this analysis, I'm guessing that my former fix fixed the problem for amd64, but not i386.) -- 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
I don't know much about this, but since there might be differences between different models, I'll add my two cents. I have a ThinkPad X60. On Tue, May 24, 2011 at 7:39 AM, David Henningsson david.hennings...@canonical.com wrote: 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. The buttons affect both the speakers and headset. When the headest is connected the speaker is muted (I don't know if this is done in software or in hardware, but I always assumed it was done in hardware as it always worked this way). I never tried usb headset, and don't have HDMI. 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? At least on my laptop alsamixer can not set the volume/mute of -c29, this can only be done by the buttons. Cheers, Tom ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Why is it still hissing?
'Twas brillig, and David Henningsson at 24/05/11 15:04 did gyre and gimble: (Btw, based on this analysis, I'm guessing that my former fix fixed the problem for amd64, but not i386.) This could be correct as when we inspected this error at my house, the server actually doing the output was indeed i386, even if my machine is x86_64... Cheers for hunting this down :D 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 change profile of bluetooth headset for different applications?
The idea of intended profile is awesome! Great thanks for sharing, Col! I'll try to implement the pseudo module as you suggested. I have a quick question: Then a separate module (module-intended-profiles?) could take care of listening quite generically for streams landing on sink and do the following logic ... Which event shall I hook for stream landing on sink, is it PA_CORE_HOOK_SINK_INPUT_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 change profile of bluetooth headset for different applications?
'Twas brillig, and Lin, Mengdong at 24/05/11 16:18 did gyre and gimble: The idea of intended profile is awesome! Great thanks for sharing, Col! I'll try to implement the pseudo module as you suggested. I have a quick question: Then a separate module (module-intended-profiles?) could take care of listening quite generically for streams landing on sink and do the following logic ... Which event shall I hook for stream landing on sink, is it PA_CORE_HOOK_SINK_INPUT_PUT? Yeah I think that's the right one I'd normally say the _NEW one, but we need to actually route things first (i.e. assign a sink to the sink-input) and thus the _PUT is likely the right one. Like I said in the last mail however, I suspect there could be problems with changing the profile here due to race conditions of calling a function inside a hook that triggers another hook, but if we're lucky there wont be any other module fiddling about that would conflict with this logic. It should be quite quick to test it all out tho' just to check that all is well :) Good luck and feel free to ask any other questions. You can also pop on IRC if you like :) Cheers 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
On Tue, May 24, 2011 at 10:13 AM, Tom Gundersen t...@jklm.no wrote: I don't know much about this, but since there might be differences between different models, I'll add my two cents. I have a ThinkPad X60. On Tue, May 24, 2011 at 7:39 AM, David Henningsson david.hennings...@canonical.com wrote: 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. The buttons affect both the speakers and headset. When the headest is connected the speaker is muted (I don't know if this is done in software or in hardware, but I always assumed it was done in hardware as it always worked this way). I never tried usb headset, and don't have HDMI. 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? At least on my laptop alsamixer can not set the volume/mute of -c29, this can only be done by the buttons. thinkpad_acpi.volume_control=1 will enable it. I don't know why the default is the way it is. If you run my patch, then you'll have a file /sys/devices/platform/thinkpad_acpi/volume_autocontrol that configures whether the mute button just mutes the mixer (latch), toggles the mixer state (toggle), or sends KEY_MUTE (none). Without the patch, depending on your model and your acpi_osi parameter, you might have the button mute the mixer *and* send KEY_MUTE or just send KEY_MUTE. The former behavior is not so nice. (My patch also prevents typematic repeat of the mute button, which is just silly.) http://permalink.gmane.org/gmane.linux.drivers.platform.x86.devel/1941 --Andy Cheers, Tom ___ 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
