[pulseaudio-discuss] pavucontrol and DISPLAY variable
Hi all, I am attempting to invoke pavucontrol on a particular X server by setting the DISPLAY environment variable. I logged in to Machine1 using Gnome. This machine runs Pulse and an X server at :0.0. I then create a xterm window from Machine1 to display on Machine2, which runs an X server at 192.168.1.3:2.0 (started with -ac, no access controls). This works fine. I check that everything's working by typing into the xterm: DISPLAY=:0.0 pavucontrol This displays the volume control on the Gnome login screen on Machine1, as expected. Finally I want to run pavucontrol to control Machine1 Pulse from the X server on Machine2, I type: DISPLAY=192.168.1.3:2.0 pavucontrol This produces three messages in the xterm: (pavucontrol:3897): atk-bridge-WARNING **: AT_SPI_REGISTRY was not started at session startup. (pavucontrol:3897): atk-bridge-WARNING **: IOR not set. (pavucontrol:3897): atk-bridge-WARNING **: Could not locate registry and then pops up a window Connection failed: Connection refused, with a close button. and finally: (pavucontrol:3897): Gtk-CRITICAL **: gtk_main_quit: assertion `main_loops != NULL' failed and exits. My questions: 1) Why does this not work as expected, displaying the volume control on the given display? 2) How can I get the volume control to display where I want? I apologise if this is outside of the Pulseaudio core function, but it does reflect a legitimate usage model for the Pulse system. Googling around for clues finds nothing sufficiently clear and specific on exactly how these things are meant to work :( Other Pulse utility programs such as pavumeter fail similarly. -- Adrian Wrigley Machine1 is running Knoppix 6.4.3 DVD started in Gnome Machine2 is running Debian Squeeze on amd64 running KDE ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pavucontrol and DISPLAY variable
Dr. Adrian Wrigley wrote: I am attempting to invoke pavucontrol on a particular X server by setting the DISPLAY environment variable. DISPLAY=192.168.1.3:2.0 pavucontrol I needed to set the following environment variable too: PULSE_SERVER=Machine1 This produces three messages in the xterm: (pavucontrol:3897): atk-bridge-WARNING **: AT_SPI_REGISTRY was not started at session startup. (pavucontrol:3897): atk-bridge-WARNING **: IOR not set. (pavucontrol:3897): atk-bridge-WARNING **: Could not locate registry The Pulesaudio applications work OK now, once the PULSE_SERVER is set. But I still get the above warning messages. How can I avoid these warnings? Other Pulse utility programs such as pavumeter fail similarly. -- Adrian Wrigley Machine1 is running Knoppix 6.4.3 DVD started in Gnome Machine2 is running Debian Squeeze on amd64 running KDE I had been confused by the atk-bridge warnings, which seem to have misdirected my search for a solution! -- Adrian ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pavucontrol and DISPLAY variable
'Twas brillig, and Dr. Adrian Wrigley at 17/01/11 18:05 did gyre and gimble: Dr. Adrian Wrigley wrote: I am attempting to invoke pavucontrol on a particular X server by setting the DISPLAY environment variable. DISPLAY=192.168.1.3:2.0 pavucontrol I needed to set the following environment variable too: PULSE_SERVER=Machine1 This produces three messages in the xterm: (pavucontrol:3897): atk-bridge-WARNING **: AT_SPI_REGISTRY was not started at session startup. (pavucontrol:3897): atk-bridge-WARNING **: IOR not set. (pavucontrol:3897): atk-bridge-WARNING **: Could not locate registry The Pulesaudio applications work OK now, once the PULSE_SERVER is set. But I still get the above warning messages. How can I avoid these warnings? I'm not 100% sure to be honest. Don't know what they are :s Other Pulse utility programs such as pavumeter fail similarly. -- Adrian Wrigley Machine1 is running Knoppix 6.4.3 DVD started in Gnome Machine2 is running Debian Squeeze on amd64 running KDE I had been confused by the atk-bridge warnings, which seem to have misdirected my search for a solution! Yeah. FWIW, if you want a little detail of why the DISPLAY variable affects things, I wrote a bit about that stuff, including remote X11 displays and SSH, here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ All the best 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] State of various rate adjustment patches
I've tested module-loopback by playing to a null-sink and looping its monitor to the real alsa sink. This showed good behaviour, but may be the algorithm I used for module-rtp-recv should also be used here. Does anyone has a better suggestion for a setup to test module-loopback? null-sink and alsa have very stable latencies, so its no good test for module-loopback. To test the loopback, what I had in mind was enabling a BT sink (receving data from somewhere else using A2DP) and playing locally on the speakers. That should trigger all kinds of latency issues since the transmitter essentially pushes packets without worrying too much about time, and the receiver has to do all the synchronization work. Should be fairly easy to enable by modifying the /etc/bluetooth/audio.conf, but I haven't had the time to test so far -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
Thanks Colin for reading my prose. Yeah, doing it server wide makes no sense IMO. The default-sample-rate configure option predates our mixer profile logic and really (IMO) somehow be wrapped up into card profiles or sink/source ports anyway, but I digress. That's actually a good point. I just took the existing default-sample-rate and built on it, but yes there's no reason to have a server default value. You could have HDMI at 192kHz, no reason to prevent higher frequencies if they were available. - To avoid quality issues, I limited the sinks to two frequencies, 44.1 or 48kHz. If we allowed for lower sampling rates, it'd be a problem if additional sink-inputs/source-outputs are created at a later stage with a higher sampling rate. This means that for a phone call or voice memo you would still see a resampling, but it should be lighter with integer instead of fractional ratios. While I see the logic behind it, it'll likely not placate all those people who want dynamic rate switching. Perhaps this will need to be extended at some point but perhaps it's a sensible starting off point. I'm thinking more of even larger frequencies rather than lower ones (although the practical usefulness could obviously be debated endlessly) Humm, I didn't follow your thinking here. - the sinks/sources only get suspended after a 5s timeout. This seems too high for sinks/sources that can be reconfigured quickly. It may make sense to have different values for the timeout, and make them dependent on the configuration latency. Or perhaps the OK to change rate logic could work when the sink is either IDLE || SUSPENDED ? That way the suspend timeout wouldn't really matter. Just a thought. I have more work to do on IDLE. This typically happens when the sink-input is corked, so you could add an SRC if for some reason the rate was changed. Even in the SUSPENDED case my USB headset seems to complain... One thing I think would be very interesting here would be cards that support hardware mixing. With these cards, would it be possible to open a stream for each of the different rates we want to use? Then when we deal with the mixing, we mix all the like-rated inputs together and send those separately to their matched device-stream? That is likely the best use of such hardware and the best implementation of support for multiple rates, but it's possibly not worth thinking about immediately due to the fact that this h/w is likely in a minority. I can see cases where you have 1 compressed stream and 1 PCM, and you mix the two in hardware, but I am having a really hard time finding a use case where you would have multiple (more than 2) PCM streams at different rates. Maybe automotive cases, where the infotainment unit might send multiple streams to a head unit were the mixing/routing is actually done? Did anyone request hardware mixing on the mailing list? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of various rate adjustment patches
2011/1/17 pl bossart bossart.nos...@gmail.com: I've tested module-loopback by playing to a null-sink and looping its monitor to the real alsa sink. This showed good behaviour, but may be the algorithm I used for module-rtp-recv should also be used here. Does anyone has a better suggestion for a setup to test module-loopback? null-sink and alsa have very stable latencies, so its no good test for module-loopback. To test the loopback, what I had in mind was enabling a BT sink (receving data from somewhere else using A2DP) and playing locally on the speakers. That should trigger all kinds of latency issues since the transmitter essentially pushes packets without worrying too much about time, and the receiver has to do all the synchronization work. Should be fairly easy to enable by modifying the /etc/bluetooth/audio.conf, but I haven't had the time to test so far -Pierre I don't have any BT equipment, so it would be great if you could test the changes. Have you experienced any wild rate variations with bluetooth in the past? If so, the current patch should at least get rid of annoying big variations. If you're interested in testing, I could also send a patch to the list where the algorithm I used for module-rtp-recv is applied module-loopback too, it would be interesting to see if it also has an improvement. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] OK, to pull bluetooth (and dbus) fixes?
Hi Colin, On Sun, Jan 16, 2011 at 4:24 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hiya Luiz, I notice a few BT related changes (including the fix for building with older dbus on your branch: git://gitorious.org/pulseaudio/mainline.git Luiz Augusto von Dentz (5): bluetooth: fix case of profile UUIDs to match what BlueZ uses bluetooth: fix build for libdbus 1.3 bluetooth: detect when bitpool has changed on sbc codec bluetooth: reduce bitpool if audio start skipping bluetooth: fix a2dp_process_push Are these ready for a pull or do they still need more testing (if it's not ready, can I merge the first two at least? (merge for ease of management to prevent rebasing at your end, otherwise I'll just cherry pick your libdbus fix); people have been tripped building master due to the dbus problem) Yep, my idea was to send a pull request already but got stuck with some other stuff, you can pull util the third one (sbc changes was already applied to BlueZ too), the last 2 I would like to give some time for testing. Regards, -- Luiz Augusto von Dentz Computer Engineer ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] OK, to pull bluetooth (and dbus) fixes?
'Twas brillig, and Luiz Augusto von Dentz at 17/01/11 21:55 did gyre and gimble: Hi Colin, On Sun, Jan 16, 2011 at 4:24 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hiya Luiz, I notice a few BT related changes (including the fix for building with older dbus on your branch: git://gitorious.org/pulseaudio/mainline.git Luiz Augusto von Dentz (5): bluetooth: fix case of profile UUIDs to match what BlueZ uses bluetooth: fix build for libdbus 1.3 bluetooth: detect when bitpool has changed on sbc codec bluetooth: reduce bitpool if audio start skipping bluetooth: fix a2dp_process_push Are these ready for a pull or do they still need more testing (if it's not ready, can I merge the first two at least? (merge for ease of management to prevent rebasing at your end, otherwise I'll just cherry pick your libdbus fix); people have been tripped building master due to the dbus problem) Yep, my idea was to send a pull request already but got stuck with some other stuff, you can pull util the third one (sbc changes was already applied to BlueZ too), the last 2 I would like to give some time for testing. Awesome, will do. I get a bit of skipping with my BT Hifi (some Samsung thing) so will see if those other patches help here. But I'll take the first three for now. Should I need the corresponding patch on libbluez to expect this to work or is it (relatively) unrelated? 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] [RFC] Dynamic reconfiguration of sampling rate
On Mon, 2011-01-17 at 14:24 -0600, pl bossart wrote: [...] I can see cases where you have 1 compressed stream and 1 PCM, and you mix the two in hardware, but I am having a really hard time finding a use case where you would have multiple (more than 2) PCM streams at different rates. Maybe automotive cases, where the infotainment unit might send multiple streams to a head unit were the mixing/routing is actually done? Did anyone request hardware mixing on the mailing list? This is something we often hear about from people with Creative SoundBlaster Live/Audigy cards and their ilk, which support hardware mixing. To some extent, the complaint is reasonable, since we're forcing resampling on CPU even though this can be off-loaded to the soundcard. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
