[pulseaudio-discuss] [0.9.17]Missing audio-headset-bluetooth icon terminates pavucontrol
If a bluetooth headset is connected and pavucontrol is started, pavucontrol terminates immediately. The only clue is when pavucontrol is started from the command-line, the following message is output: terminate called after throwing an instance of 'Gtk::IconThemeError' Aborted Supplying a replacement audio-headset-bluetooth.svg (eg, in $HOME/.icons) avoids the terminate and shows the icon on the Output Devices tab and Input Devices tab. The terminate also occurs if the headset is connected while pavucontrol is running. Tested with pulseaudio-0.9.17, bluez-4.52 on 2.6.31 kernel. Regards, Peter Hurley PS - I saw the open call for art - is this likely to happen with other device configurations as well? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [0.9.17]Missing audio-headset-bluetooth icon terminates pavucontrol
On Fri, 18.09.09 09:30, Peter Hurley (phur...@charter.net) wrote: If a bluetooth headset is connected and pavucontrol is started, pavucontrol terminates immediately. The only clue is when pavucontrol is started from the command-line, the following message is output: terminate called after throwing an instance of 'Gtk::IconThemeError' Aborted This has been fixed in pavucontrol a while back. Please update! Supplying a replacement audio-headset-bluetooth.svg (eg, in $HOME/.icons) avoids the terminate and shows the icon on the Output Devices tab and Input Devices tab. The terminate also occurs if the headset is connected while pavucontrol is running. Tested with pulseaudio-0.9.17, bluez-4.52 on 2.6.31 kernel. Regards, Peter Hurley PS - I saw the open call for art - is this likely to happen with other device configurations as well? Yes. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [0.9.17]Missing audio-headset-bluetooth icon terminates pavucontrol
Lennart Poettering wrote: This has been fixed in pavucontrol a while back. Please update! Thanks - I thought I was running the current release. Somehow I overlooked the announcement of 0.9.9... Peter ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [0.9.17]Missing audio-headset-bluetooth icon terminates pavucontrol
Peter Hurley wrote: Lennart Poettering wrote: This has been fixed in pavucontrol a while back. Please update! Thanks - I thought I was running the current release. Somehow I overlooked the announcement of 0.9.9... Peter Hi Lennart, Turns out this is more easily said than done. The new libcanberra dependency is a fair bit of work to resolve. Also, I'm not clear why the udev detection code isn't considered experimental in pulseaudio. Deprecating module-detect already seems a bit hasty. module-udev-detect depends on a version of udev that's barely 3 months old. Additionally, even with the revised udev, some fairly graceless means of making that work are employed. Based on the shortcomings of udev exposed by pulseaudio's usage, perhaps pushing for a more appropriate udev messaging sequence/device enumeration/driver status makes sense? Regards, Peter ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [0.9.17]Missing audio-headset-bluetooth icon terminates pavucontrol
On Fri, Sep 18, 2009 at 02:28:48PM -0400, Peter Hurley wrote: Peter Hurley wrote: Lennart Poettering wrote: This has been fixed in pavucontrol a while back. Please update! Thanks - I thought I was running the current release. Somehow I overlooked the announcement of 0.9.9... Peter Hi Lennart, Turns out this is more easily said than done. The new libcanberra dependency is a fair bit of work to resolve. Also, I'm not clear why the udev detection code isn't considered experimental in pulseaudio. Deprecating module-detect already seems a bit hasty. module-udev-detect depends on a version of udev that's barely 3 months old. Additionally, even with the revised udev, some fairly graceless means of making that work are employed. Sorry, you are complaining that software which itself is one week old use another part, which is 3 month old? If you can't upgrade udev or scared to do so, because udev looks like low-level part of system, you shouldn't touch PA. PA is quite low-level and critical also, its integration should be handled by distribution maintainers. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [0.9.17]Missing audio-headset-bluetooth icon terminates pavucontrol
On Fri, 18.09.09 14:28, Peter Hurley (phur...@charter.net) wrote: Hi Lennart, Heya, Turns out this is more easily said than done. The new libcanberra dependency is a fair bit of work to resolve. They invented distributions so that you don't have deal with dependencies. Also, I'm not clear why the udev detection code isn't considered experimental in pulseaudio. Deprecating module-detect already seems a bit hasty. module-udev-detect depends on a version of udev that's barely 3 months old. Additionally, even with the revised udev, some fairly graceless means of making that work are employed. PA makes use of features from the latest kernel, latest udev, latest gcc, latest glibc. I cannot see what could be wrong with that. PA is after all a low-level component of today's Linux system, so either upgrade it with the rest of the OS, or don't at all. Based on the shortcomings of udev exposed by pulseaudio's usage, Shortcomings? perhaps pushing for a more appropriate udev messaging sequence/device enumeration/driver status makes sense? I don't see why. I have been working with upstream udev to integrate the necessary work in udev upstream, and hence I depend on a recent udev version. What you are asking me instread is adding all kinds of wrkarounds to PA itself to keep compat with old udev versions? That would be simply the wrong way, problems should be fixed where they are, not worked around. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [0.9.17]Missing audio-headset-bluetooth icon terminates pavucontrol
A distro like Gentoo would help you in this case if you want to be selective about piece meal upgrades but still there is some pain if mixing bleeding edge libraries with more stable software. I tried to move on to this PA and the dependencies were difficult to deal with so I postponed testing of it until later. :) Fred Frigerio On Fri, Sep 18, 2009 at 2:50 PM, Lennart Poettering lenn...@poettering.netwrote: On Fri, 18.09.09 14:28, Peter Hurley (phur...@charter.net) wrote: Hi Lennart, Heya, Turns out this is more easily said than done. The new libcanberra dependency is a fair bit of work to resolve. They invented distributions so that you don't have deal with dependencies. Also, I'm not clear why the udev detection code isn't considered experimental in pulseaudio. Deprecating module-detect already seems a bit hasty. module-udev-detect depends on a version of udev that's barely 3 months old. Additionally, even with the revised udev, some fairly graceless means of making that work are employed. PA makes use of features from the latest kernel, latest udev, latest gcc, latest glibc. I cannot see what could be wrong with that. PA is after all a low-level component of today's Linux system, so either upgrade it with the rest of the OS, or don't at all. Based on the shortcomings of udev exposed by pulseaudio's usage, Shortcomings? perhaps pushing for a more appropriate udev messaging sequence/device enumeration/driver status makes sense? I don't see why. I have been working with upstream udev to integrate the necessary work in udev upstream, and hence I depend on a recent udev version. What you are asking me instread is adding all kinds of wrkarounds to PA itself to keep compat with old udev versions? That would be simply the wrong way, problems should be fixed where they are, not worked around. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ 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
