[pulseaudio-discuss] What-did-you-plugin-dialog
David Henningsson
david.henningsson at canonical.com
Mon Dec 2 22:45:39 PST 2013
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...
Also, given my currently very limited time I don't have the time to
implement jacks/port groups, and given your limited time, you likely
don't have time to review it. As such, it seems there is no use in
trying to upstream any solution right now.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
More information about the pulseaudio-discuss
mailing list