[pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Brian J. Murrell
brian at interlinx.bc.ca
Wed Oct 28 19:53:52 PDT 2009
Disclaimer: I don't really have any skin in this game so you can tell me
I'm stupid or whatever you want, however...
On Mon, 2009-10-26 at 16:05 +0100, Lennart Poettering wrote:
> Yepp, and I'd argue the non-xinerama setup is useless.
/me looks over from his primary display (with it's separate desktops.
separate panels and where he can't drag windows -- but he can drag
desktop icons -- so nautilus is a bit more knowledgeable than the window
manager is about screens, but I digress) to the e-mail he is composing
on his secondary, non-xinerama'd display.
Been doing it that way for the better part of a decade. Xinerama seems
more useless to me than this. With Xinerama, do I really want most
windows (terminals, web-browsing, e-mail composing and reading) split
across a physical monitor barrier where there is a few inches of
"plastic" between the screen real-estate? Not usually.
So what (would I, were I using Xinerama) do I do most of the time with
windows that do open up split between two screens? I (would) move them
in one direction or another to get them entirely on one of the physical
screens. So if that's how I am going to operate, why bother with
Xinerama and its' particular short-coming(s), at which separate screens
is good, like being able to easily maximize an application to use up a
full physical monitor, but no more and yet no less. Yes I could stretch
it out from corner to corner of a separate screen, but that maximize
button is so handy. And I cannot switch viewports independently on the
two screens with Xinerama, which reduces the usefulness of keeping
something displayed on one screen all the time while I flip viewports on
the other screen.
Another very good use case (and this one is going to segue into this
particular thread very well in a minute) is the computer in the bedroom.
Another dual-head machine (that's 2-0 for dual-head vs. xinerama in my
house) that does not use Xinerama.
Why's that? Because it's composed of a real monitor on screen 0 and an
LCD TV on screen 1. Regular desktop computing (e-mail, browsing,
playing games, doing homework, etc.) is done on screen 0 and on screen 1
there is a MythTV instance left running (for the convenience of just
having to turn on the TV to watch). So the bedroom computer doubles as
the family computer as well as the bedroom TV (for a value of TV that
Now, how this fits with OP's original propsal is that the TV in this
setup has it's own speakers which are being driven by a separate sound
card in this machine. This machine also has it's own speakers a
different sound-card. So two sets of speakers, two sound cards.
So as for why two... I don't want to have to turn on the TV just to get
sound for gaming (or music while "computing", etc.) on screen 0 but I
also want to have MythTV's audio come through the TV's speakers, where
the picture is coming from. It's just natural to have the sound come
from where you are looking.
Of course, I've hobbled this together to work with Pulse's static sound
routing, where I've mapped mythtv to use the sound card connected to the
TV and everything else defaults to the "other" sound card.
But that means if I use MythTV on screen 0 (for whatever strange
reason), I do have to turn the TV on to get sound, (or mess with the PA
routing of course, but then also remember to fix it when I am done).
But if OP's proposal were accepted such that one could choose to route
sound to hardware by the screen the application is running on (with the
existing per application overrides still effective of course), this
would all "just work" for me too.
> I don't think this is a realistic use-case. It's very much fabricated.
Really? The above dual-screen configuration I have in my bedroom where
one screen is a TV is fabricated? I'll have to go tell the wife to stop
watching, right now. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the pulseaudio-discuss