On 2011-06-28 17:35, Takashi Iwai wrote:
At Tue, 28 Jun 2011 17:27:15 +0100, David Henningsson wrote:
On 2011-06-27 13:07, Mark Brown wrote:
On Mon, Jun 20, 2011 at 03:37:25PM +0200, David Henningsson wrote:
- We're continuing the path with /dev/input devices
2a) We'll rewrite these devices to be read-only ALSA mixer controls
2b) We'll rewrite these devices to be something within ALSA, but not exactly mixer controls.
For options 2a) and 2b) I guess the existing /dev/input thing should be deprecated and/or removed. So part of decision should maybe be based on information about how widespread the usage of these devices are currently...?
So, this discussion seems to have ground to a halt.
Yes, unfortunately, and without a clear consensus. That puts me in a difficult position, because I'm trying to get the job done. And very preferrable, in the next release of Ubuntu (which is to be released on October this year). I've been talking to a few of my colleagues here at Canonical, and here's how we reason currently:
We have the input layer. We also have a set of patches for supporting this in PulseAudio (although currently unmerged and I'm not sure about their current quality/state).
So, the targets are already defined, i.e. what information is actually required? This wasn't very clear to me until now.
Well, for basic jack detection the current input layer will work. We might want to add some more information to it (e g by changing the name string or use the additional fields available), but that should not be very controversial, I think.
However, if we manage to expose all the routing between PCMs, volume controls and ports, we can make an even better PulseAudio, because we can solve other problems as well, such as the volume control naming problem. But figuring out how to do that in the best way API-wise and so on, I guess that will take some time.
We don't have the alternative Alsa Control API discussed in this thread. Without taking a stance of whether that would be a better solution or not, designing it will take some time - somewhat depending on the set of problems we're aiming to solve. Regardless, it will definitely not reach the 3.0 kernel (which is what we will ship in the next release of Ubuntu).
If only the same functionality is required as currently done in the input-jack layer, re-implementing the jack-detection elements in ALSA control API is pretty easy.
Yes, but it is not clear to me that this is the decision, and what we actually want to do. So far I have only seen Kay and Lennart advocating for it and Mark against it. I started off this thread because I needed a decision, but so far no clear decision has been made.
It means that the control element would have some jack name with a location prefix or such, reports the current jack status, and notifies the jack change. That's all. Optionally, it can have a TLV data giving the HD-audio jack attribute, too.
I guess this will require support in alsa-lib as well then? At least if you want to pass through new types of TLV data.
As already mentioned, the difficulties of implementation mainly depends on the requirements. If just a flat array without structural connection is enough, it's easy, of course.
But, it definitely won't reach to 3.0 kernel. So, maybe this won't help in your case, anyway...
Well, if the changes are not too invasive, there is also the possibility to backport things into the Ubuntu version of the 3.0 kernel as well.