'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble:
>> Here is my proposal:
>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
> In my humble opinion....
>
> Device by media.role is not that great.. it stand up for events, but
> it should really be be per client (application)
>
> The major use cases i have right now that suck... and are not solvable
> without prior knowledge of how pa works
> 1 - If I plug in my USB or Bluetooth headset the music does not
> change to headset like my analogue headset does...
With your analogue headset "music" does not change to it, all output
changes to it. I know what you're hinting at, but the two cannot be
compared unless you just talk about "all output".
With my proposal, "music" could be configured to move to the new
USB/bluetooth headset.
> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
> not be set to use that mic without restarting skype?
Incorrect. When PA is used, Skype detects it and uses only it. It
(correctly) does not offer you the configuration choice inside Skype. It
is mostly up to tools like gnome-volume-control/pavucontrol etc. to
configure the Skype streams, but in the case of a USB or Bluetooth
headset, the PA module module-intended-roles kicks in and automatically
moves "voip" streams to "headset" devices. This currently works pretty
well (I don't have to do any configuration after setting up my bluetooth
headset for it to "just work" with Skype. It's quite nice, but not very
transparent. If you read the link I sent through, I believe I proposed
there (maybe it was afterwards on the list - can't quite recall) that
module-intended-roles becomes a passive module that simply injects brand
new (never seen before) devices into the appropriate place in the
priority list for the appropriate role. That way it's more transparent
to the user and the net functionality remains the same.
> 3 - There no way to easily set the media role or an app that dosn't
> have one (yes the all should have a role but they don't), pa could be
> doing better here using desktop files and the role should be saved..
PA *does* use .desktop files. That's what module-augment-properties does...
> 4 - Videos do not cork music
No they don't. Currently the automatic corking is implemented by
module-cork-music-on-phone. This could be made more generic with some
kind of simple "rules" file that could be parsed at startup to allow
"video corks music". That would be kinda sensible IMO.
> By default I think pa should:
> - Move all inputs and outputs to any newly connected local device (ie
> usb, bluetooth whatever) that appears after pa has started (unless the
> per client device has been set of course)
Perhaps, but I don't think everyone would agree here. I certainly would
not be appropriate for my crappy bluetooth headset here. It's acceptable
for phone streams, but really not for anything else.
> - There should be a simple UI for setting a clients default media
> role (if one has not been set), and this role should be remembered by
> pa
This could be done, but I'd personally rather not do it. An alternative
would be an independent "database" (like pci.ids or usb.ids) that could
"know" which apps are which roles, that we can update via the web and
bundle when we release, but I think letting users do this removes from
the simplicity that should underlie this system. If the user cares that
much, they can either edit the .desktop file or create a wrapper
script/alias that sets the relevant env vars to allow for role to be forced.
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video
Not quite sure how easy this would be, but in theory if the client has a
proplist, it should be easy to make any streams that client creates
inherit that (I'd have to check to see if this is not done already!)
> - A module to cork music when video is playing
Should be trivial to do (although depending on the options and
combinations here it may be better to parse some simple rules (or just
rename module-cork-on-phone and call it module-auto-cork or something
and implement this extra rule (tho' I guess separate modules give users
more control).
> Those 4 things would solve every problem I can think of and make pa
> function as I think 90% desktop users expect
I think most points are valid. With the exception of the first one, the
others are not technically that much related to routing (the role points
are related if you assume most routing is role-based (at least
initially)) and as such are probably orthoganal to the routing overhaul
I suggest.
Certainly worth keeping in mind tho'.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
___________________________________________________
Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.
