At Mon, 03 Dec 2012 14:43:37 +0100, David Henningsson wrote:
On 11/30/2012 10:39 AM, Takashi Iwai wrote:
At Fri, 30 Nov 2012 09:46:29 +0100, David Henningsson wrote:
On 11/30/2012 08:57 AM, Takashi Iwai wrote:
At Fri, 30 Nov 2012 01:33:27 +0100, David Henningsson wrote:
I would recommend a user to use hda-jack-retask in these cases, instead of cluttering the kernel code.
Well, hda-jack-retask is a nice debugging tool, but it's not intended for the actual user interface for daily use.
Maybe we should consider making the reconfiguration more lightweight in the kernel then, so that hda-jack-retask (or a more simplistic GUI) can be used for daily use?
I don't think any tool accessing hwdep to fiddle with the codec verb isn't suitable for normal usage. For any normal usage, the only access is via control API.
Trying to summarise this long thread, we seem to advocate these two options as I see it:
- Use the hwdep interface:
Pro: Simplest kernel code
Pro: Can support more options, higher degree of freedom for user
Con: Any reconfiguration is a bit disturbing and can e g break currently running audio streams.
Con: (Currently) requires root privileges to change, since it works through the hwdep interface.
Con: how can you ensure the exclusive setup and the exclusive access? Imagine multiple sessions are using different configurations.
Con: how would you manage the mixer elements from hwdep at all? There are independent mixer applications.
- Base reconfiguration on jack-mode controls
Pro: Simpler for user to reconfigure jacks
Con: More complex kernel code than first option
Con: It might be difficult to get the volume/switch control names right in all scenarios.
Con: Needs work in PulseAudios and GUIs to support jack retasking better, or it will be either unsupported (for the average user) or confusing.
Hmm... I don't get it. How can hda-jack-retask or whatever be a better option than PA? The integration work for PA is more or less necessary. Launching another application may be more confusion for user, no?
Also; since the parsing code is still separate between codecs, we have to implement all of this complexity over and over again...
It's "still". They will be merged sooner or later, anyway.
Probably we can sort out most stuff with option 2) too, I mean, with the capture source, automute and autoswitch, rerouting paths, repurposing DACs, and all that, but the question is really, should we? Are we willing to take the cost of the added complexity that comes with it? Are we be able to get it right, or do we get several broken kernel versions before we get something that works really well?
I don't think it'll be too complex in the end. We'll be reducing the code while merging such a new feature, especially by unifying the codes from multiple drivers. Once after this gets done, the driver will cover all needed demands for IDT, Conexant, Cirrus and VIA, and most of AD and C-Media codecs. Let's see.
Also, a big missing piece is the automatic retasking via jack detection as a headphone.
Through impedance sensing? Does the ALC221 support that?
No. Otherwise it'd be easier :)
Ok, so what do you mean with "automatic"?
Sorry, it wasn't automatic "retasking" but muting.
Windows have capabilities to tune each jack as well. This is a long-standing TODO, and I think "* Jack Mode" enum is the natural way to implement it. (How to let user setting it is another question. I can imagine that PA could ask user once when a jack is detected.)
Btw, how "disturbing" is it when you retask jacks on Windows? What happens e g if you try to retask a jack you're currently outputting audio to?
I don't know exactly, too.
But if we expose the capture source, it may conflict. One way to avoid it is to make the capture source inactive on the fly in auto mic mode. The question is how robust PA is, whether it's screwed up by such a change...
I don't know either...I mean, there is no dynamic reconfiguration, but whether it will crash or just simply ignore that it can't set the capture source I don't know. Try and see :-)
Btw, I was trying to figure out what PulseAudio version you're actually using for your enablement. I guess it's 0.9.23? [1]
Yeah, the primary requirement is that one, but I've been checking also with 2.0 and 2.1.
How important is it for you to actually get support for this stuff in PulseAudio? I mean, you're certainly more than capable of adding kcontrols, but I've never seen you - or anyone else from your team - submitting patches against PulseAudio to have support for these things all the way through to the user.
Honestly, I don't care at this moment at all. A part of the reason is that I don't use PulseAudio on my machines.
But for normal users, PA support would be a really "good to have".
But still I think the method of creating more and more Jack Mode controls will lead to more long term maintenance problems (as the kernel code complexity increases), compared to implementing a more lightweight reconfiguration mechanism.
I don't think jack mode control itself would be too messy. From the top view, it provides either bias level and possibly I/O switch that makes this jack hooking to the existing output route. Thus, this doesn't disturb others.
Of course, your concern is about the combination of auto-mic and jack mode enums. That can be more different.
As an example. Say that we have three DACs with amp-outs. In standard configuration the first DAC's volume control is called "Speaker Volume" and the second DAC's volume is called "Headphone Volume". Suddenly you get a Jack Mode switch or multi-I/O switch, so that the three DACs now go to "Front", "C/LFE" and "Rear". The headphone must then be rerouted to the first DAC. But what happens to the volume controls now?
No. This doesn't happen.
The additional output via jack mode enum is just a hook to the existing I/O topology. It can hook to "Headphone" volume as a secondary headphone, but nothing else. If it can't to hook the headphone volume, no option will be provided.
If more drastic change is needed, user has to reconfigure the whole topology by setting the initial pin configs.
Instead of my previous patches, we can start of implementing jack mode enums at first. This allows the implementation of a lightweight jack retasking in user-space. Again, these enum controls won't provide the all possible retasking. They provide only cases where no drastic topology change is needed. This will serve most of user's demands, I guess. If not, user needs to create a better initial configuration for own demands.
What if there suddenly is "demand for such feature" for something that *does* change the topology a lot?
Again, it doesn't change the topology. If it needs to change the topology, it's not what we support in the mixer API. This needs reconfiguration, thus it essentially needs to restart the whole driver functionality.
Takashi