On 2015-03-31 19:32, Tanu Kaskinen wrote:
On Mon, 2015-03-30 at 09:54 +0200, David Henningsson wrote:
On 2015-02-12 14:11, Tanu Kaskinen wrote:
"JackHWMute" is a UCM device value that, if set, indicates that the
jack of the device mutes some other device at the hardware or driver
level. A common example would be a headphone jack that mutes built-in
speakers. PulseAudio should show such auto-muted devices as
unavailable.
Previously there was only a simple relationship: each UCM device was
related to one jack and vice versa. Now each device is still related
to exactly one jack, but each jack can be related to two devices: one
that the jack enables, and one that the jack disables (mutes).
Sorry for chiming in this late, but...
Can we instead duplicate the jack, like we do for non-UCM, and set
jack->state_plugged -> PA_AVAILABLE_NO / jack->state_unplugged ->
PA_AVAILABLE_YES for the HWMute jack functionality?
I suppose that's possible. I dislike that, because it means that the
jack object doesn't actually represent a jack at all, not even a jack
kcontrol. Instead, it represents the association between a device and a
jack kcontrol. But if you prefer to do it that way, I'll do it that way.
I'd hate to tell a person to start from scratch again just based on my
preference - Arun, what do you think?
Some background on why I wrote the patch as I did: I would like to have
only one jack object per physical jack, but that's unfortunately not
possible, because there may be multiple jack kcontrols per physical
jack, and AFAIK there's no API to find out about related jack kcontrols.
The next best thing would be to have one jack object for each jack
kcontrol, but I decided that since I'm anyway going to have to give up
on the "one jack object per physical jack" ideal, maybe it's better to
just use the model that UCM uses. In UCM, jacks are per-device things
(meaning that each device has to repeat the jack configuration if there
are multiple devices using the same jack), so I created one jack per UCM
device. Now you want to further increase the duplication, with the
benefit that the jack model in the UCM code would match the traditional
mixer code, at the cost of introducing a mismatch with the underlying
UCM model. I can live with that.
I'm trying to understand how this description fits with your actual
patch, but I'm having troubles understanding how the objects fit together.
First, you add both "port" and "pa_alsa_ucm_port" structs. What's the
difference? Also, both contain pointers to variable called "core_port".
Does this also mean there are non-core ports? What's the difference
between a "core_port" and "non-core ports"?
Second, a pa_alsa_ucm_device has an array of pa_alsa_ucm_ports, and a
pa_alsa_ucm_port has an array of pa_alsa_ucm_devices. I have a hard time
understanding this, could you give a realistic example where there is
more than one port per device that in turn has more than one device per
port?
Third, JackHWMute per UCM documentation says something like "this jack
mutes another device". If the availability of ucm devices are solely set
by the jack (right?), then this is effectively a ucm_device to
ucm_device connection, where you can set one ucm_device's availability
based solely on the other ucm_device. I don't really see why you need to
add these crossreference port structs at all.
Another thing: you said jack->state_unplugged would set the state to
PA_AVAILABLE_YES, but in the traditional mixer config speakers are set
to state PA_AVAILABLE_UNKNOWN when headphones are unplugged. Do you
think it should be different with UCM?
Sorry, I'll correct myself. It would be better to toggle between NO and
UNKNOWN, for consistency. That said; I'd want the non-UCM stuff ideally
to toggle between NO and YES too, but that's a different discussion.
It looks like this would enable us to share code between UCM and non-UCM
code paths instead of duplicating similar functionality.
Also, we would then get automatic support for use cases like "Line Out"
which should only be available if both a) "Line Out Jack" is plugged in
and b) "Headphone Jack" is unplugged.
In my patch I decided to not support a situation where one jack makes a
device available and another jack makes it unavailable, because of the
ambiguity. If we want to support the use case you mention, I guess the
UCM spec should explicitly say that JackHWMute overrides JackControl,
otherwise we'd be relying on undefined behaviour.
Actually I'd say it's an "and" relation rather than one overrides the
other; i e, the device is available only if (JackControl.plugged_in &&
!JackHWMute.plugged_in).
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
