Bug 39704

This is all already possible with PulseAudio via module-device-manager.

It's actually how things work under KDE for the last couple years.

While it's possible to use under GNOME the only GUI currently available is under KDE.

The intention is to move things into PA core (rather than keep them separated out in a separate module).

This is also (broadly) the topic of my talk at this years Desktop Summit in just a few days.

I've also been writing about this problem for a loooong time. But only now am I really in a position to actually do the work.

See here:
http://pulseaudio.org/wiki/KDE
 but more specifically here:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Also note that devices which report themselves as headset or handset form factor will automatically be used for voip applications. This is already possible via module-intended-roles, although I personally do not like how it works (it actively moves the streams - I would prefer such automated logic merely manipulated a priority list on the very first observation that such a device exists, and thereafter just used the priority list as "normal" (and thus incorporating any user customisation made after initial insertion).

(I meant to say, please get in touch if you are going to the Desktop Summit for further discussions on this. This is the perfect time to give input on the topic and the DS is the perfect place to do it. But if you are not going, then there is still plenty opportunity to liaise about it!)

(In reply to comment #2)
> (I meant to say, please get in touch if you are going to the Desktop Summit for
> further discussions on this. This is the perfect time to give input on the
> topic and the DS is the perfect place to do it. But if you are not going, then
> there is still plenty opportunity to liaise about it!)

Sadly I will not be able to attend the Desktop Summit. However, I was doing a bit more thinking and instead of requiring applications to report whether they are chat applications or not, PulseAudio could have a list of known streams from them that are and reroute them to the appropriate device group.

Just another thought. But yeah, I have reported this to GNOME 3 as well with the GNOME end of things and the blog article that pulls it all together, but no comments yet so I am still waiting on that end.

Anyway, I am perfectly willing to talk to both sides of the equation about ways to get this done (and perhaps other desktop project developers as well), so if we could set up some sort of discussion that would be nice. I just did the blog entry since I knew of no other way to get the ideas all in one place at the time. If all else fails I suppose we can get a good chat going and you could bring it up at the DS. Anyway, going to read your blog post now. :)

(In reply to comment #3)
> (In reply to comment #2)
> > (I meant to say, please get in touch if you are going to the Desktop Summit for
> > further discussions on this. This is the perfect time to give input on the
> > topic and the DS is the perfect place to do it. But if you are not going, then
> > there is still plenty opportunity to liaise about it!)
> 
> Sadly I will not be able to attend the Desktop Summit.

That's a shame. Please do join our mailing list and hang out on our IRC channel as lots of this stuff gets covered there (and the list isn't super high traffic).

> However, I was doing a
> bit more thinking and instead of requiring applications to report whether they
> are chat applications or not, PulseAudio could have a list of known streams
> from them that are and reroute them to the appropriate device group.

This is already possible actually. Apps can inform us of their "media.role" via a stream proplist. If the app does not fill in this metadata we attempt to automatically augment this metadata via module-augment-properties. It does this via reading the corresponding .desktop file and reading the Category= entry and attempts to map that to our list of known roles. It's not perfect (especially for voip apps where the "ringing" or "buddy signed in/out" sounds should be marked as "event" sounds, but the actual conversations and calls should be marked as "voip" sounds - the augmentation stuff cannot really do much about knowing which sounds are which in this case, especially if the app only opens one stream to PA and mux's all it's sounds itself.


Some VoIP tools already provide nice metadata. Both Empathy and Skype do for example (there may still be some tagging bugs in Skype tho' - don't think I've tested their most recent version).

> Anyway, I am perfectly willing to talk to both sides of the equation about ways
> to get this done (and perhaps other desktop project developers as well), so if
> we could set up some sort of discussion that would be nice. I just did the blog
> entry since I knew of no other way to get the ideas all in one place at the
> time. If all else fails I suppose we can get a good chat going and you could
> bring it up at the DS. Anyway, going to read your blog post now. :)

Yeah, rest assured there is already work going on in this area :)

Please do feel free to participate and I'll try and do some good right ups of the DS stuff.

I'm also forming a "PulseAudio Planet" where anything linux audio related on blogs can go, so if you think you'll be writing more pieces on PA and how it fits into any desktop env, please do send me and RSS feed (tag specific to PA) so that I can add it into the loop :)

Cheers

Col

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/537.