Re: [pulseaudio-discuss] Bluetooth headset on Karmic
On Sat, Nov 14, 2009 at 5:01 AM, Josu Lazkano josu.lazk...@gmail.comwrote: Thanks for all, so I am going to contact with bluez folks. Yes the BT hardware is diferent, this the one that not work: (...) Manufacturer: Broadcom Corporation (15) And this is the one that works: (now runing Debian Lenny) (...) Manufacturer: Cambridge Silicon Radio (10) In my experience CSR bluetooth dongles are better supported than Broadcom. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Sat, 2009-10-31 at 07:55 +0800, Ng Oon-Ee wrote: On Fri, 2009-10-30 at 18:43 +0100, Lennart Poettering wrote: And that's why I am saying that multiple screens per display is just a pointless excercise, since it gives you exactly NOTHING that multiple montors per screen wouldn't give you -- no, it takes features away. Sorry Lennart, in my (gaming) case, it allows the monitors to be placed a distance from each other, such that the mouse pointer cannot cross over. I use a small app (mouse-switchscreen) to allow the pointer to cross over if I want (ie. when not playing games). The other thing he mentioned which can't be done on xinerama is independent view-ports, where switching viewports on monitor 1 doesn't affect what's showing on monitor 2. Everyone has their own use-case =). But I think this is going pretty off-topic for the pulse list? Let me chip in another user-case: 1 monitor 2 TV; TV not always connected and in another room. I think we agree that Xinerama does not cut it in this case. Multiple displays? Maybe, but: NVidia *and* ATI graphical tools make it easy to set up a dual screen. To set up dual display, you have to get yourself dirty with xorg.conf - not an option for 90% of users. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Look at pulseaudio.desktop and start-pulseaudio-x11. These do exactly that just now. The script would need modified for this use case (as it registers X session handler too, not just the publication) but in theory, just running start-pulseaudio-x11 on each display should get you the necessary gubbins loaded (albeit one of session modules will fail to load, but you can probably just ignore that - the error is suppressed anyway). Hmm.. in that case my patch does not finish the job - potential users still have to modify the /usr/bin/start-pulseaudio-x11 binary in order to load the modules the right way. Couldn't we have something like '/etc/pulse/x11.conf' which would be read by /usr/bin/start-pulseaudio-x11 ? I could cook something like that together, but would that be accepted? Comments? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Well, the patch is there; you can go apply it, then load two 'module-x11-publish' : load-module module-x11-publish display=:0.0 sink=foo load-module module-x11-publish display=:0.1 sink=bar and voilla! It's working automagically. ( BTW, what is the best way to load the modules? I put the above two lines in /etc/pulse/default.pa, and it's working, but there's a comment there 'X11 modules should not be started from default.pa so that one daemon can be shared by multiple sessions' . So how? ) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] attach X11 properties to Screen, not Display
1) Formatting corrected
2) Fallback to screen 0 added. It works:
leszek# pax11publish -D :0.0 -d
Server:
{571eae318b6377f95367e6524abdec09}unix:/home/leszek/.pulse/571eae318b6377f95367e6524abdec09-runtime/native
Sink: alsa_output.pci-_01_06.0.analog-stereo
Cookie:
3ac2381a17c704d94ef0edb1b8fdf289ff003587b59a45d6ae3aa0f3c1586032192d180896ffb9412193d7531ea1c869e53c3c3ffb9c2c5fcd0dd036baccdac959992a599fa398823fb35d61a07fd17466e095cc00ffa22c9c14ff9d982ee368c6c16c24014b150bbed5facac7b37c35507b4fb73d9d0bd2efe22bbd4f86a7de42d8d105c8900ecc3462f0dece7d1a6b845275b095a301112544f1409ab3beb84989bc5ae19459b57c3415275334b849824659c9696e6c797d46be53d0957831569fa9a535713a8a1f216cfa7aeb6d6faa35f4b9a7fed5f4fc21dfb47ca9514f26fd118f09836e5c2308be49254189d967c20d258a65cd1fc2d4aa2f2652
leszek# pax11publish -D :0.1 -d
Server:
{571eae318b6377f95367e6524abdec09}unix:/home/leszek/.pulse/571eae318b6377f95367e6524abdec09-runtime/native
Sink: alsa_output.pci-_00_07.0.analog-stereo
Cookie:
3ac2381a17c704d94ef0edb1b8fdf289ff003587b59a45d6ae3aa0f3c1586032192d180896ffb9412193d7531ea1c869e53c3c3ffb9c2c5fcd0dd036baccdac959992a599fa398823fb35d61a07fd17466e095cc00ffa22c9c14ff9d982ee368c6c16c24014b150bbed5facac7b37c35507b4fb73d9d0bd2efe22bbd4f86a7de42d8d105c8900ecc3462f0dece7d1a6b845275b095a301112544f1409ab3beb84989bc5ae19459b57c3415275334b849824659c9696e6c797d46be53d0957831569fa9a535713a8a1f216cfa7aeb6d6faa35f4b9a7fed5f4fc21dfb47ca9514f26fd118f09836e5c2308be49254189d967c20d258a65cd1fc2d4aa2f2652
leszek# xprop -root -display :0.1 -remove PULSE_SINK
leszek# pax11publish -D :0.1 -d
Server:
{571eae318b6377f95367e6524abdec09}unix:/home/leszek/.pulse/571eae318b6377f95367e6524abdec09-runtime/native
Sink: alsa_output.pci-_01_06.0.analog-stereo
Cookie:
3ac2381a17c704d94ef0edb1b8fdf289ff003587b59a45d6ae3aa0f3c1586032192d180896ffb9412193d7531ea1c869e53c3c3ffb9c2c5fcd0dd036baccdac959992a599fa398823fb35d61a07fd17466e095cc00ffa22c9c14ff9d982ee368c6c16c24014b150bbed5facac7b37c35507b4fb73d9d0bd2efe22bbd4f86a7de42d8d105c8900ecc3462f0dece7d1a6b845275b095a301112544f1409ab3beb84989bc5ae19459b57c3415275334b849824659c9696e6c797d46be53d0957831569fa9a535713a8a1f216cfa7aeb6d6faa35f4b9a7fed5f4fc21dfb47ca9514f26fd118f09836e5c2308be49254189d967c20d258a65cd1fc2d4aa2f2652
diff -Naur pulseaudio-0.9.19-old/src/pulsecore/x11prop.c
pulseaudio-0.9.19-new/src/pulsecore/x11prop.c
--- pulseaudio-0.9.19-old/src/pulsecore/x11prop.c 2009-10-26
23:07:57.0 +0800
+++ pulseaudio-0.9.19-new/src/pulsecore/x11prop.c 2009-10-27
19:29:39.0 +0800
@@ -32,12 +32,12 @@
void pa_x11_set_prop(Display *d, const char *name, const char *data) {
Atom a = XInternAtom(d, name, False);
-XChangeProperty(d, RootWindow(d, 0), a, XA_STRING, 8, PropModeReplace,
(const unsigned char*) data, (int) (strlen(data)+1));
+XChangeProperty(d, DefaultRootWindow(d), a, XA_STRING, 8, PropModeReplace,
(const unsigned char*) data, (int) (strlen(data)+1));
}
void pa_x11_del_prop(Display *d, const char *name) {
Atom a = XInternAtom(d, name, False);
-XDeleteProperty(d, RootWindow(d, 0), a);
+XDeleteProperty(d, DefaultRootWindow(d), a);
}
char* pa_x11_get_prop(Display *d, const char *name, char *p, size_t l) {
@@ -47,13 +47,21 @@
unsigned long nbytes_after;
unsigned char *prop = NULL;
char *ret = NULL;
+int window_ret;
Atom a = XInternAtom(d, name, False);
-if (XGetWindowProperty(d, RootWindow(d, 0), a, 0, (long) ((l+2)/4), False,
XA_STRING, actual_type, actual_format, nitems, nbytes_after, prop) !=
Success)
-goto finish;
+
+window_ret = XGetWindowProperty(d, DefaultRootWindow(d), a, 0, (long)
((l+2)/4), False, XA_STRING, actual_type, actual_format, nitems,
nbytes_after, prop);
-if (actual_type != XA_STRING)
-goto finish;
+if( window_ret != Success || actual_type != XA_STRING ) {
+if( DefaultScreen(d) != 0 ) {
+window_ret = XGetWindowProperty(d, RootWindow(d,0), a, 0, (long)
((l+2)/4), False, XA_STRING, actual_type, actual_format, nitems,
nbytes_after, prop);
+
+if( window_ret != Success || actual_type != XA_STRING )
+goto finish;
+}
+else goto finish;
+}
memcpy(p, prop, nitems);
p[nitems] = 0;
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Yepp, and I'd argue the non-xinerama setup is useless. (...) I long had a feeling that I am being a pest with my dual screen, no-one seems to like it :) Least of all the people in the Gnome mailinglist... 1) Think about this usercase (that I already wrote about before): - a monitor and a soundcard 1 - a TV, standing in another room, soundcard 2 - bluetooth mouse keyboard. Connect the TV to your nvidia TV-out; fire up 'nvidia-settings'; setup the TV. You've got 2 options: - 'separate X screen' - 'TwinView' ( xinerama ) since TV is in another room, Xinerama makes little sense and actually makes things harder ( mostly because various windows which are supposed to pop up in the center of the screen pop up between the monitor and TV and you cannot easily see them, especially since the TV is most of the time disconnected! ) So you set up the separate X screen. This works very nicely (apart from a few little bugs in Gnome-panel ) You can enjoy watching movies or picture slides on your TV. It's really much better than Xinerama. ** Furthermore, I already have a simple patch which IMHO does not screw up anything for the single-monitor and Xinerama people while ALMOST-WORKING ;) for all those dual-screen pests. I'll post it in another message. L. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] attach X11 properties to Screen, not Display
The patch below attaches X11 properties to a Screen, not a Display. Using
it, I am able to do the following:
leszek# pax11publish -D :0.0 -O alsa_output.pci-_01_06.0.analog-stereo
-e
leszek# pax11publish -D :0.1 -O alsa_output.pci-_00_07.0.analog-stereo
-e
leszek# xprop -root -display :0.0 | grep PULSE
PULSE_COOKIE(STRING) =
3ac2381a17c704d94ef0edb1b8fdf289ff003587b59a45d6ae3aa0f3c1586032192d180896ffb9412193d7531ea1c869e53c3c3ffb9c2c5fcd0dd036baccdac959992a599fa398823fb35d61a07fd17466e095cc00ffa22c9c14ff9d982ee368c6c16c24014b150bbed5facac7b37c35507b4fb73d9d0bd2efe22bbd4f86a7de42d8d105c8900ecc3462f0dece7d1a6b845275b095a301112544f1409ab3beb84989bc5ae19459b57c3415275334b849824659c9696e6c797d46be53d0957831569fa9a535713a8a1f216cfa7aeb6d6faa35f4b9a7fed5f4fc21dfb47ca9514f26fd118f09836e5c2308be49254189d967c20d258a65cd1fc2d4aa2f2652
PULSE_SINK(STRING) = alsa_output.pci-_01_06.0.analog-stereo
PULSE_SERVER(STRING) = leszek-desktop
PULSE_SESSION_ID(STRING) =
571eae318b6377f95367e6524abdec09-1256566213.375419-376893987
leszek# xprop -root -display :0.1 | grep PULSE
PULSE_COOKIE(STRING) =
3ac2381a17c704d94ef0edb1b8fdf289ff003587b59a45d6ae3aa0f3c1586032192d180896ffb9412193d7531ea1c869e53c3c3ffb9c2c5fcd0dd036baccdac959992a599fa398823fb35d61a07fd17466e095cc00ffa22c9c14ff9d982ee368c6c16c24014b150bbed5facac7b37c35507b4fb73d9d0bd2efe22bbd4f86a7de42d8d105c8900ecc3462f0dece7d1a6b845275b095a301112544f1409ab3beb84989bc5ae19459b57c3415275334b849824659c9696e6c797d46be53d0957831569fa9a535713a8a1f216cfa7aeb6d6faa35f4b9a7fed5f4fc21dfb47ca9514f26fd118f09836e5c2308be49254189d967c20d258a65cd1fc2d4aa2f2652
PULSE_SINK(STRING) = alsa_output.pci-_00_07.0.analog-stereo
PULSE_SERVER(STRING) = leszek-desktop
Now I try playing something from :0.0 - sound correctly gets routed to
alsa_output.pci-_01_06.0.analog-stereo
However when I try to play something from :0.1, all I can hear is silence. I
notice that for some reason PULSE_SESSION is missing from :0.1's root
window. I add it:
leszek# xprop -root -display :0.1 -f PULSE_SESSION_ID 8s -set
PULSE_SESSION_ID
571eae318b6377f95367e6524abdec09-1256566213.375419-376893987
..and everything works!
Apart the problem with PULSE_SESSION, there is another one: the above
confuses gnome-volume-manager which seems to completely disregard the X11
props.
*
diff -Naur pulseaudio-0.9.19-old/src/pulsecore/x11prop.c
pulseaudio-0.9.19-new/src/pulsecore/x11prop.c
--- pulseaudio-0.9.19-old/src/pulsecore/x11prop.c2009-10-26
23:07:57.0 +0800
+++ pulseaudio-0.9.19-new/src/pulsecore/x11prop.c2009-10-26
22:36:46.0 +0800
@@ -32,12 +32,12 @@
void pa_x11_set_prop(Display *d, const char *name, const char *data) {
Atom a = XInternAtom(d, name, False);
-XChangeProperty(d, RootWindow(d, 0), a, XA_STRING, 8, PropModeReplace,
(const unsigned char*) data, (int) (strlen(data)+1));
+XChangeProperty(d, DefaultRootWindow(d), a, XA_STRING, 8,
PropModeReplace, (const unsigned char*) data, (int) (strlen(data)+1));
}
void pa_x11_del_prop(Display *d, const char *name) {
Atom a = XInternAtom(d, name, False);
-XDeleteProperty(d, RootWindow(d, 0), a);
+XDeleteProperty(d, DefaultRootWindow(d), a);
}
char* pa_x11_get_prop(Display *d, const char *name, char *p, size_t l) {
@@ -49,7 +49,7 @@
char *ret = NULL;
Atom a = XInternAtom(d, name, False);
-if (XGetWindowProperty(d, RootWindow(d, 0), a, 0, (long) ((l+2)/4),
False, XA_STRING, actual_type, actual_format, nitems, nbytes_after,
prop) != Success)
+if (XGetWindowProperty(d, DefaultRootWindow(d), a, 0, (long) ((l+2)/4),
False, XA_STRING, actual_type, actual_format, nitems, nbytes_after,
prop) != Success)
goto finish;
if (actual_type != XA_STRING)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] attach X11 properties to Screen, not Display
Cool. The above patch actually fully works. One kjust has to load two modules-x11-publish: pactl load-module module-x11-publish display=:0.0 sink=alsa_output.pci-_01_06.0.analog-stereo pactl load-module module-x11-publish display=:0.1 sink=alsa_output.pci-_00_07.0.analog-stereo ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] PulseAudio ignores X11 properties of screens
( continuation of a thread about my 'dual screen' setup: 'Automatic
selection of an audio sink depending on value of ENV variable ' )
I've got 1 X server running and 2 screens: 0.0 and 0.1; 2 soundcards:
les...@leszek-desktop:~$ pacmd list-sinks | grep name | grep output
name: alsa_output.pci-_00_07.0.analog-stereo
name: alsa_output.pci-_01_06.0.analog-stereo
I would like to set up Pulse so that whenever I'm in 0.0, sound gets
routed to alsa_output.pci-_01_06.0.analog-stereo, and whenever I
work in 0.1 - to alsa_output.pci-_00_07.0.analog-stereo.
I've been advised that Pulse is able to get its default sink from X
properties of the root window. Let's try then:
*
leszek# pax11publish -D :0.0 -O
alsa_output.pci-_01_06.0.analog-stereo -e
leszek# pax11publish -D :0.1 -O
alsa_output.pci-_00_07.0.analog-stereo -e
leszek# xprop -root | grep PULSE ## on monitor 0.0
PULSE_COOKIE(STRING) =
3ac2381a17c704d94ef0edb1b8fdf289ff003587b59a45d6ae3aa0f3c1586032192d180896ffb9412193d7531ea1c869e53c3c3ffb9c2c5fcd0dd036baccdac959992a599fa398823fb35d61a07fd17466e095cc00ffa22c9c14ff9d982ee368c6c16c24014b150bbed5facac7b37c35507b4fb73d9d0bd2efe22bbd4f86a7de42d8d105c8900ecc3462f0dece7d1a6b845275b095a301112544f1409ab3beb84989bc5ae19459b57c3415275334b849824659c9696e6c797d46be53d0957831569fa9a535713a8a1f216cfa7aeb6d6faa35f4b9a7fed5f4fc21dfb47ca9514f26fd118f09836e5c2308be49254189d967c20d258a65cd1fc2d4aa2f2652
PULSE_SINK(STRING) = alsa_output.pci-_00_07.0.analog-stereo
PULSE_SERVER(STRING) = leszek-desktop
PULSE_SESSION_ID(STRING) =
571eae318b6377f95367e6524abdec09-1256048477.493671-985655645
leszek# xprop -root | grep PULSE ## on TV 0.1
(nothing)
And sound always goes to alsa_output.pci-_00_07.0.analog-stereo.
pax11publish ignores screen numbers.
*
But maybe I can set the properties manually? Let's try then:
## on 0.0
leszek# xprop -root -f PULSE_SINK 8s -set PULSE_SINK
alsa_output.pci-_01_06.0.analog-stereo
leszek# xprop -root | grep PULSE
PULSE_SINK(STRING) = alsa_output.pci-_01_06.0.analog-stereo
PULSE_COOKIE(STRING) =
3ac2381a17c704d94ef0edb1b8fdf289ff003587b59a45d6ae3aa0f3c1586032192d180896ffb9412193d7531ea1c869e53c3c3ffb9c2c5fcd0dd036baccdac959992a599fa398823fb35d61a07fd17466e095cc00ffa22c9c14ff9d982ee368c6c16c24014b150bbed5facac7b37c35507b4fb73d9d0bd2efe22bbd4f86a7de42d8d105c8900ecc3462f0dece7d1a6b845275b095a301112544f1409ab3beb84989bc5ae19459b57c3415275334b849824659c9696e6c797d46be53d0957831569fa9a535713a8a1f216cfa7aeb6d6faa35f4b9a7fed5f4fc21dfb47ca9514f26fd118f09836e5c2308be49254189d967c20d258a65cd1fc2d4aa2f2652
PULSE_SERVER(STRING) =
{571eae318b6377f95367e6524abdec09}unix:/home/leszek/.pulse/571eae318b6377f95367e6524abdec09-runtime/native
PULSE_SESSION_ID(STRING) =
571eae318b6377f95367e6524abdec09-1256446499.571891-1748126058
PULSE_ID(STRING) = 1...@571eae318b6377f95367e6524abdec09/2747
## on 0.1
leszek# xprop -root -f PULSE_SINK 8s -set PULSE_SINK
alsa_output.pci-_00_07.0.analog-stereo
leszek# xprop -root | grep PULSE
PULSE_SINK(STRING) = alsa_output.pci-_00_07.0.analog-stereo
So far so good, but when in screen 0.1 I try launching, say, Audacious - its
sound still gets sent to alsa_output.pci-_01_06.0.analog-stereo.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Tue, 2009-10-20 at 18:32 +0200, Michał Sawicz wrote: Dnia 2009-10-20, wto o godzinie 17:18 +0100, Colin Guthrie pisze: Did you try setting the xprops manually? Make sure that works first (although if pax11publish is looking at the wrong display, it could be the pulse client libs are doing the same...) Doesn't 0.0 and 0.1 mean there's only one root window - thus only one default sink to be set through pax11publish? leszek# xprop -root -display :0.1 -f TEST 8s -set TEST test0.1 leszek# xprop -root -display :0.0 -f TEST 8s -set TEST test0.0 leszek# xprop -root -display :0.0 | grep TEST TEST(STRING) = test0.0 leszek# xprop -root -display :0.1 | grep TEST TEST(STRING) = test0.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Here's my usercase: I've got a monitor and sound card hw:0.0 set up as my primary video/audio sinks. I've also got a TV , located in a different room, connected to a TV-Out and to another sound card, hw:1.0 I've also got a Bluetooth keyboard and mouse. So whenever I want to watch a video or show my guests a picture slideshow , I simply connect the (looong!) vidao/audio cables to the TV, move the keyboard and mouse (still work from ~8m away! ) and lie down on the sofa :) The TV is a separate X screen ( why would I use Xinerama? I don't need to move windows between the displays ) so when an application is launched on the monitor, DISPLAY is set to 0.0 and when I operate on the TV, it is 1.0. I hope you already know what I have in mind: the above works wonderfully, except for the sound. Every time I work on the TV, the sound should be sent to hw:1.0, so I have to fire up the new 'gnome-sound-properties 2.28' (BTW, wonderful app! simple and effective) and select hw:1.0 to be the audio sink for now. Worse, since the TV is on 2nd X screen, 'gnome-sound-properties' applet won't start there ( it claims there is already one running - sure there is, on the monitor - and refuses to start ). So it order to change the audio sink, I have to haul my lazy butt back to the monitor. Now, I would make me one happy duck if I could somehow tell Pulse to automatically route audio to hw:1.0 whenever I am working on the TV, that is, whenever DISPLAY is 1.0. Is that possible? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Ok, thanks guys! Pulse Convert On Mon, Oct 19, 2009 at 6:20 PM, Jeremy Visser jer...@visser.name wrote: On Mon, 2009-10-19 at 16:38 +0800, Leszek Koltunski wrote: Every time I work on the TV, the sound should be sent to hw:1.0, so I have to fire up the new 'gnome-sound-properties 2.28' (BTW, wonderful app! simple and effective) and select hw:1.0 to be the audio sink for now. Worse, since the TV is on 2nd X screen, 'gnome-sound-properties' applet won't start there ( it claims there is already one running - sure there is, on the monitor - and refuses to start ). Now I don't necessarily agree with their stance, but it is generally not regarded a good idea to have the same user logged in to the same GNOME profile twice. I know — I get bitten by this too when I want to set up a multiseat kiosk-type setup. If you want a solution that 'just works', then either log off your primary display, or use a separate user with a separate GNOME profile. (This is a bug in GNOME though, IMO, not your fault.) ___ 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
[pulseaudio-discuss] Pulse with a bluetooth headset
Hello Pulse gurus,
I am a long time Debian user. My current audio setup:
- 1 Soundblaster Live ( snd-emu10k1x ) hardware soundcard
- 1 bluetooth headset to with I send audio with help of the recently
developed audio subsystem of the BlueZ stack ( more info:
http://wiki.bluez.org/ )
here's the bluetooth-related section of my ~/.asoundrc:
pcm.headset_hw {
type bluetooth
device 00:07:a4:b5:7a:bb
}
ctl.headset {
type bluetooth
device 00:07:a4:b5:7a:bb
}
pcm.headset {
type plug
slave.pcm headset_hw
}
I dont use any ESDs, jacks, artsds or OSSes - just plain ALSA with dmix.
***
Here are all audio related things I would like to accomplish:
1) be able to send sound from MPlayer to both sinks
Current status: works with no problems with 'mplayer -ao
alsa:device=default' and 'mplayer -ao alsa:device=headset'
2) be able to send sound from Audacious to both sinks
Current status: works, audacious can be graphically reconfigured to send
audio either to headset virtual sndcard or default sndcard.
3) be able to send sound from FlashPlugin 9 to both sinks
Current status: works wonderfully with 'default' ALSA sink; I dont know
how to send audio to 'headset' ( maybe if I redefined 'default' to
type bluetooth device 00:07:a4:b5:7a:bb in my ~/.asoundrc FlashPlugin
would send sound there, but I haven't tried )
4) Be able to capture and send sounds from Skype to/from both the headset
and the default
Current status: capturing/sending audio to default works. To headset
it does not. On Skype forums they blame bluez for this, on bluez
forum they claim Skype's ALSA usage is incredibly weird.
5) I would also like to be able to send multiple sounds to the same
soundcard simultanously
Current status: lovingly works.
6) I would like to be able to dynamically change sinks, i.e. open up
application X and be able to switch its audio sink frm headset to default
while the application is running. I would like to be able to do this
consistantly in the same way regardless of the application.
Current status: doesn't work.
I don't care about Gnome system sounds, VLC, XINE or any other audio
app.
***
Looks like PulseAudio can help me with the issues, especially 6). After
reading Pulse's documentation I have the impression that simply installing
Pulse and adding the following section to my .asoundrc
pcm.!default
{
type pulse
}
ctl.!default
{
type pulse
}
will retain all my existing functionality and fix issue 6). Furthermore,
looks like PulseAudio even has a tray app from where I can dynamically
change sinks and adjust volume levels per app.
Is that correct? Any comments?
thaks in advance,
Leszek
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulse with a bluetooth headset
Yes, that is correct. As long as your ALSA devices are set to pulse you can use the pulse mixer for everything and get rid of dmix altogether. (Pulse does a much better job of this IMO.) Note that SOME ALSA applications won't work right with the pulse emulation, and OSS support using padsp isn't quite perfect. For example, VirtualBox, which uses ALSA natively, doesn't work right with pulse. And snes9x that uses OSS, doesn't work with padsp. The only option for it is to either use dmix along with pulse (bad idea), or use pasuspender which will completely suspend the pulse server while the app is running. Oh yeah, I do use VirtualBox. But sound in it is not essential, and during the rare occurence when I do use it, I suppose I can do the pasuspender thing. I don't care about OSS at all. How about FlashPlugin 9 ? Can it use the virtual 'pulse' ALSA device? I hoped that anything which can output sound to a hardware ALSA soundcard can also use a virtual ALSA card, but as we can see with Skype + BlueZ-audio and VirtualBox + pulse, this is not always the case... *** Has anyone on this list tried to use Pulse with bluetooth headsets? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulse with a bluetooth headset
There is a plugin for flash (libflashsupport) for this. flashplugin's
built in alsa support used to be buggy and would kill pulse - not sure
if it still is tho'.
I dont understand why one needs any special libraries. FlashPlugin
can already output sound to an alsa device.So if I add the pcm.!default {
type pulse } to my asoundrc, and if pulse correctly implements the ALSA
API, any application that correctly uses the API - including FlashPlugin
- should be able to just transparently use the new 'default' device, am I
wrong?
If that's not the case, I claim something is seriously wrong with Linux
audio system.
I suspect that someone will want to write a bluetooth headset plugin for
pulse that can detect when a bluetooth headset is activated (which would
essentially replace the need to have the bt mac addr in asoundrc. It
could be intelligent enough to be configured so that streams with a
certain regexp are automatically moved such that if e.g. skype or ekiga
is mid call and I just open my headset, by the time I fit to to my ears
pulse has already moved the stream across that is theoretically
possible but not implemented yet.
Why would we need that? IMHO, the existing bluez-audio does it very well
already. I hope I can just define a virtual ALSA device called 'headset'
of type 'bluetooth' just like in my asoundrc above, and then Pulse should
be able to - completely transparently - treat this device just like it was
a hardware sound card. Can it do that?
The automatic sending of Skype or Ekiga streams to the headset can already
be done, can't it? I mean, documentation says that one can assign default
audio sinks to individual applications?
L.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
