[PATCH 4/5] chtrt5645: Remove bogus JackHWMute settings

[Jaroslav Kysela]

Dne 06. 04. 20 v 18:58 Hans de Goede napsal(a):
> Hi,
> 
> On 4/6/20 5:17 PM, Pierre-Louis Bossart wrote:
>>
>>>> So overall it seems rather unlikely that we can support dmic + headset mic in parallel?
>>>
>>> Right that is what the ConflictingDevices sections are for.
>>>
>>> Removing the JackHWMute does not allow using both add the same time,
>>> it merely allows overriding which of the 2 to use (if the headset mic
>>> is detected by the jack, the JackControl setting is kept).
>>>
>>> So lets say the internal mic is crappy, but the user prefers to
>>> have their ears free, then they can use a headset around there neck,
>>> using just the headset-mic and select speakers as output even though
>>> a jack is inserted.
>>>
>>> Note pulseaudio will still automatically switch to the headphones /
>>> headsetmic when plugged in, this merely allows overriding that
>>> choice manually.
>>>
>>> Jacks which actually physically disable (or re-route) signals are
>>> quite rare now a days so having a JackHWMute in the UCM conf is
>>> often wrong. After this patch only a few cases are left:
>>>
>>> [hans at x1 alsa-ucm-conf]$ ack -l JackHWMute ucm2
>>> ucm2/HDA-Intel/HiFi-dual.conf
>>> ucm2/chtrt5650/HiFi.conf
>>> ucm2/hda-dsp/HiFi.conf
>>> ucm2/codecs/es8316/HeadPhones.conf
>>> ucm2/sof-bdw-rt5677/HiFi.conf
>>> ucm2/broxton-rt298/HiFi.conf
>>> ucm2/skylake-rt286/HiFi.conf
>>>
>>> The es8316 case is actually correct, the es8316 has only 1
>>> output (which is amplified for e.g. a speaker) and at
>>> least the reference design suggests routing the speaker signal
>>> through the jack and using a jack which will interrupt the
>>> signal when headphones are plugged in.
>>>
>>> Note most actual designs implement this with an analog
>>> switch and a GPIO to control that switch, since 3.5 mm
>>> jacks which actually can disconnect a signal are rare
>>> (if they exist at all, but I guess they do). For the
>>> designs using the GPIO controlled analog switch, the
>>> JackHWMute technically also is wrong, but I put it
>>> there (IIRC it was me) because it matches the reference
>>> design.
>>>
>>> I'm not familiar enough with any of the others to say anything
>>> about them, but most of them are for HDA setups, where this
>>> is somewhat more normal I guess.
>>
>> If I follow the logic, I guess we should also remove the JackHWMute for sof-bdw-rt5677, hda-dsp and HDA-Intel. I can't think of a hardware limitation preventing the headset mic from being used while the speakers are used for playback. Likewise the rt5650 is a cheaper version of rt5645 so the same applies.
> 
> Right AFAIK:
> 
> JackHWMute "foo"
> 
> Means that the JackControl listed in the same section does
> something at the hardware level which makes it impossible
> for the "foo" input / output to function until the jack
> is removed. Typically this would be something like actually
> disconnecting the speakers at the electrical level.
> 
> So almost always using it is wrong.

I agree. The description is really straight (use-case.h):

"Note that JackHWMute should be used only when the hardware enforces the 
automatic muting."

Pierre, it seems that hds-dsp uses JackHWMute for Speaker and Headphones, I 
think that it should be removed. Otherwise PA thinks that those devices cannot 
be used simultaneously when user wants to..

					Jaroslav


> 
> Regards,
> 
> Hans
> 
> 


-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.