[pulseaudio-discuss] What-did-you-plugin-dialog

[Tanu Kaskinen]

On Tue, 2013-12-03 at 14:45 +0800, David Henningsson wrote:
> 2013-11-29 23:55, Tanu Kaskinen skrev:
> > On Fri, 2013-11-29 at 14:22 +0800, David Henningsson wrote:
> >> 2013-11-29 00:39, Tanu Kaskinen skrev:
> >>> I have been thinking about this problem a bit, and it looks to me like
> >>> our sink, source and port concepts don't fit this use case very well.
> >>> The user plugs something to a jack, and the user should select the mode
> >>> for the jack. A sink is not the same thing as a jack, and a port is not
> >>> the same thing as a jack. I think we should have "jack" as a core
> >>> concept and expose the jacks to clients, so that clients can set the
> >>> jack mode when necessary. That's of course a fair bit of work...
> >> I think it's true that our port concept does not fit exactly to the
> >> jacks, especially not as you have made ports unidirectional. But I don't
> >> think the solution to the problem is to introduce *yet* another core
> >> concept. It's just too much complexity added to the core for one minor
> >> edge case problem.
> > I think we'll just have to agree to disagree here.
> >
> > So, you won't add the jack concept to the core. How would you feel about
> > exposing a similar client interface from a module instead of the core?
> > Make it possible to list all jacks in the system, get notifications
> > about their state changes (when something is plugged in), and make it
> > possible for clients to set the jack mode for jacks that can't detect
> > the right mode themselves?
> >
> Thinking more about this, actually this is not the only case where a 
> "jack" concept would apply. We also have the mic in / line in feature 
> added for some IDT codecs.
> Another thing is being able to switch a mic in + line in + line out into 
> 5.1 output, but not sure if that is as easy to model.
> 
> As such, maybe the jack is no longer an edge case. I was thinking along 
> the lines of making a light-weight jack concept (I've called it 
> port-group) using port properties, e g by adding
> 
> (for analog-output-headphones)
> port-group=headset
> port-group-modes=headphones, headset
> 
> (for analog-input-headset-mic)
> port-group=headset
> port-group-modes=headset
> 
> (for analog-input-headphone-mic)
> port-group=headset
> port-group-modes=microphone
> 
> ...or something. That wouldn't be terribly complex to do, but still 
> double the code size (i e, compared to hard-coding the ports).
> 
> However, extending that thought, that begs for *another* rewrite of the 
> Gnome UI to use port groups as their main concept rather than 
> ports...eeek...

Regarding the "main concept" of the Gnome UI... I think we're talking
about routing here? Is there any single "main concept" anyway? Doesn't
the Gnome UI already handle both sinks and ports as routing targets? So
there's no single main concept that would cover everything. I don't know
how port groups could be the main concept, but perhaps you just mean
that the Gnome UI should understand what it means if a port belongs to a
port group, similarly how the Gnome UI needs to understand what it means
if a sink has ports.

I could throw nodes to this discussion too, but I don't think they are
any kind of magic bullet for UIs. The node API should make it simpler
for the Gnome UI to activate a given route, but the Gnome UI probably
still has to understand something about the lower level concepts below
the nodes, if it wants to present streams and devices differently to the
user. I don't know what you'd like the Gnome UI to do with the
jacks/port groups, but obviously you have something in mind, and nodes
probably won't offer a solution for whatever that is that you're
thinking about.

-- 
Tanu