Re: [pulseaudio-discuss] Bluetooth headset on Karmic
On Sat, Nov 14, 2009 at 5:01 AM, Josu Lazkano wrote: > 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] [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] [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] 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
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
> > fixable. In this particular case outlined in this thread it seems to > be requested to make those props per-screen and not per-display. Yes > We can do this, Not sure it makes a lot of sense though in the general > case, and makes we wonder how long before someone wants to attach this > informaton to a monitor, not a screen or display. > > And then again, running a display with multiple screens is kinda > exotic in my eyes. The more common case is to have one screen with > multiple monitors. And that's what we should optimize for. > > I'll try to argue with the above. If one runs NVidia proprietary drivers ( last time I used ATI - ~3ys ago - it was the same over there ) and wants to connect more than one monitor, NVidia offers two ways to do it: you can setup the second monitor to be what they call a "separate X screen" ( and that it precisely what I have here ) or a "TwinView" (nvidia-speak for Xinerama ). Now, the main difference between those two modes is this: Xinerama connects 2 or more monitors into one big desktop (gnome panels stretch across both monitors, one can drag windows between them etc ) whereas 'separate X screen' creates 2 separate desktops (2 copies of gnome-panels appear, one on each monitor, dragging is impossible, each monitor has its own icons, trays etc ) . That means that if one chooses Xinerama, most probably his monitors are located physically next to each other. But in this case he likely does NOT need a separate sound sink for each monitor! If however one goes for 'separate X screen' , then he most probably wants some kind of a multiseat setup, or maybe - like in my case - his monitors are far away from each other. In precisely this case people tend to need separate sound sinks. Current strategy of attaching an X prop to a display gives this flexibility only to those who are knowledgeable enough to set this up manually in xorg.conf; NVidia and ATI graphical tools cannot do it. Attaching X prop to a screen would give this flexibility to 'dual screen' users, and those actually tend to need it. Going for 'seperate sound sink for each monitor' first of all would require a radical redesign of Pulse, and second would not result in much additional benefit ( only Xinerama people would potentially gain, but those do not need this functionality anyway ) > But hey, a clean patch can be a very convincing argument. Walk the > walk, don't talk the talk! > I'll see what I can do. ___ 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] 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: name: 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
> As the others already pointed out, the X11 props stuff is what you > want. > > Try something along these lines: > > $ pax11publish -D :0 -O foobar -e > $ pax11publish -D :1 -O waldo -e > > Where foobar and waldo are the two logical PA sink names to use. First, a clarification: I was wrong saying that my TV is "1.0" - turns out I am running one X server and 2 X screens, "0.0" and "0.1". ** So here's what I've tried: leszek# pacmd list-sinks | grep name | grep output name: name: leszek# pax11publish -D ":0.0" -O alsa_output.pci-_01_06.0.analog-stereo -e leszek# xprop -root | grep PULSE ## on monitor "0.0" 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-1256048477.493671-985655645" Not I try to play something from 0.0 - it gets played to the correct ( i.e. alsa_output.pci-_01_06.0.analog-stereo ) soundcard. Now I try leszek# pax11publish -D ":0.0" -O alsa_output.pci-_00_07.0.analog-stereo -e and I try playing something - it correctly gets played to alsa_output.pci-_00_07.0.analog-stereo. So far, so good. Now the final test: lets match the soundcard with the X screen: 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 the sound always gets played to the TV's soundcard ( alsa_output.pci-_00_07.0.analog-stereo ), no matter if I fire up my SoundApp from TV or monitor. Seems to me that 'pax11publish' disregards the screen number given in its -D parameter and only pays attantion to the X server number. for every N, pax11publish -D ":0.N" overwrites the X11 properties of "0.0". What am I missing here? ___ 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
> 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.) > > I am not logged in twice. I don't know how it used to be before, but Gnome 2.26 and 2.28 in that case simply present GDM login screen only on the monitor and when I log in 2 instances of Gnome DE appear on both screens. When I log off from the monitor, TV also gets logged out. ___ 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 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] 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] 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
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
[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