ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
# Generic handling of analog microphones on HDA devices
|
|
|
|
|
|
|
|
|
|
# Microphone related variables on entry
|
2026-01-13 16:41:35 +01:00
|
|
|
# MicType == "hda" # HDA microphone
|
|
|
|
|
# MicType != "hda" # other microphone type (AMD 'acp', Intel 'sof-dsp')
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
|
|
|
|
|
# Microphone related variables as used internally
|
|
|
|
|
# HDA codecs can offer input source selection (mux) via "Input Source" or
|
2026-07-01 16:41:23 +02:00
|
|
|
# "Capture Source" with varying options '[PREFIX ]Mic' where PREFIX is
|
|
|
|
|
# <Empty>,Internal,Headset,Headphone.
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
#
|
|
|
|
|
# or there can be 'Mic' and optional 'Front Mic' available
|
|
|
|
|
#
|
2026-07-01 16:41:23 +02:00
|
|
|
# There is also third variant - driver supports auto-switching. In
|
|
|
|
|
# this case, the '[Prefix ]Mic Boost Volume' controls exists. There are also
|
|
|
|
|
# phantom jacks exported by the driver in this case, but it's not
|
|
|
|
|
# necessary to use them. Prefixes: <Empty>,Internal,Front
|
|
|
|
|
#
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
# This leads to up to maximum of four possible input devices.
|
|
|
|
|
|
|
|
|
|
Define.SourceControl ""
|
2026-01-13 16:41:35 +01:00
|
|
|
Define.MicExtraPriority 0
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
Define.MicJackControl ""
|
2025-03-28 11:48:07 +01:00
|
|
|
Define.MicHPJackControl ""
|
|
|
|
|
Define.MicHSJackControl ""
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
|
|
|
|
|
# evaluate the microphone jack name
|
2025-03-28 11:48:07 +01:00
|
|
|
If.micjack {
|
|
|
|
|
Condition {
|
|
|
|
|
Type ControlExists
|
|
|
|
|
Control "iface=CARD,name='Mic Jack'"
|
|
|
|
|
}
|
|
|
|
|
True.Define.MicJackControl "Mic Jack"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
If.hsjack {
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
Condition {
|
|
|
|
|
Type ControlExists
|
|
|
|
|
Control "iface=CARD,name='Headset Mic Jack'"
|
|
|
|
|
}
|
2025-03-28 11:48:07 +01:00
|
|
|
True.Define.MicHSJackControl "Headset Mic Jack"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
If.hpjack {
|
|
|
|
|
Condition {
|
|
|
|
|
Type ControlExists
|
|
|
|
|
Control "iface=CARD,name='Headphone Mic Jack'"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
2025-03-28 11:48:07 +01:00
|
|
|
True.Define.MicHPJackControl "Headphone Mic Jack"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
If.jacksel1 {
|
|
|
|
|
Condition {
|
|
|
|
|
Type String
|
|
|
|
|
Empty "${var:MicJackControl}"
|
|
|
|
|
}
|
|
|
|
|
True.Define.MicJackControl "${var:MicHPJackControl}"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
If.jacksel2 {
|
|
|
|
|
Condition {
|
|
|
|
|
Type String
|
|
|
|
|
Empty "${var:MicJackControl}"
|
|
|
|
|
}
|
|
|
|
|
True.Define.MicJackControl "${var:MicHSJackControl}"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
If.jacksel3 {
|
|
|
|
|
Condition {
|
|
|
|
|
Type String
|
|
|
|
|
Empty "${var:MicHPJackControl}"
|
|
|
|
|
}
|
|
|
|
|
True.Define.MicHPJackControl "${var:MicJackControl}"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
If.jacksel4 {
|
|
|
|
|
Condition {
|
|
|
|
|
Type String
|
|
|
|
|
Empty "${var:MicHSJackControl}"
|
|
|
|
|
}
|
|
|
|
|
True.Define.MicHSJackControl "${var:MicJackControl}"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# determine the name of the source selection enum, if present
|
|
|
|
|
If.inputsourcectl {
|
|
|
|
|
Condition {
|
|
|
|
|
Type ControlExists
|
|
|
|
|
Control "name='Input Source'"
|
|
|
|
|
}
|
|
|
|
|
True.Define.SourceControl "Input Source"
|
|
|
|
|
False.If.capturesourcectl {
|
|
|
|
|
Condition {
|
|
|
|
|
Type ControlExists
|
|
|
|
|
Control "name='Capture Source'"
|
|
|
|
|
}
|
|
|
|
|
True.Define.SourceControl "Capture Source"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2026-01-13 16:41:35 +01:00
|
|
|
# Extra priority for systems with DMIC presence (MicType != 'hda')
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
If.micdevs {
|
|
|
|
|
Condition {
|
|
|
|
|
Type String
|
2026-01-13 16:41:35 +01:00
|
|
|
String1 "${var:MicType}"
|
|
|
|
|
String2 "hda"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
2026-01-13 16:41:35 +01:00
|
|
|
False.Define.MicExtraPriority 100
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# Macro HDAMicEnum - Create the SectionDevice for HDA inputs
|
|
|
|
|
#
|
|
|
|
|
# Arguments:
|
|
|
|
|
# DevName - Name of the device (used as SectionDevice."${var:__DevName}"
|
|
|
|
|
# Enum - Name of the source/input enum
|
|
|
|
|
# Comment - Long name of the SectionDevice
|
|
|
|
|
# Jack - Jack control if available
|
|
|
|
|
# Priority - CapturePriority
|
|
|
|
|
DefineMacro.HDAMicEnum.SectionDevice."${var:__DevName}" {
|
|
|
|
|
Comment "${var:__Comment}"
|
|
|
|
|
|
|
|
|
|
EnableSequence [
|
|
|
|
|
cset "name='${var:SourceControl}' '${var:__Enum}'"
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
Value {
|
|
|
|
|
CapturePriority "${eval:($__Priority+$MicExtraPriority)}"
|
|
|
|
|
CapturePCM "hw:${CardId}"
|
|
|
|
|
CaptureMixerElem "Capture"
|
|
|
|
|
CaptureVolume "Capture Volume"
|
|
|
|
|
CaptureSwitch "Capture Switch"
|
|
|
|
|
CaptureMasterElem "${var:__Enum} Boost"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
2026-01-13 16:41:35 +01:00
|
|
|
If.jack {
|
|
|
|
|
Condition {
|
|
|
|
|
Type String
|
|
|
|
|
Empty "${var:-__Jack}"
|
|
|
|
|
}
|
|
|
|
|
False.Value.JackControl "${var:__Jack}"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ConflictingDevice [
|
|
|
|
|
"Mic:hda-int"
|
|
|
|
|
"Mic:hda-hp"
|
|
|
|
|
"Mic:hda"
|
|
|
|
|
"Headset:hda-mic"
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# Macro HDAMicSwitch - Create the SectionDevice for HDA inputs (switches)
|
|
|
|
|
#
|
|
|
|
|
# Arguments:
|
|
|
|
|
# DevName - Name of the device (used as SectionDevice."${var:__DevName}"
|
|
|
|
|
# Name - Name of the controls
|
|
|
|
|
# Comment - Long name of the SectionDevice
|
|
|
|
|
# Jack - Jack control if available
|
|
|
|
|
# Priority - CapturePriority
|
|
|
|
|
DefineMacro.HDAMicSwitch.SectionDevice."${var:__DevName}" {
|
|
|
|
|
Comment "${var:__Comment}"
|
|
|
|
|
|
|
|
|
|
Value {
|
|
|
|
|
CapturePriority "${eval:($__Priority+$MicExtraPriority)}"
|
|
|
|
|
CapturePCM "hw:${CardId}"
|
|
|
|
|
CaptureMixerElem "${var:__Name}"
|
|
|
|
|
CaptureVolume "${var:__Name} Volume"
|
|
|
|
|
CaptureSwitch "${var:__Name} Switch"
|
|
|
|
|
CaptureMasterElem "${var:__Name} Boost"
|
2026-07-01 16:41:23 +02:00
|
|
|
JackControl "${var:-__Jack}"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
If.micsetup {
|
|
|
|
|
Condition {
|
|
|
|
|
Type String
|
|
|
|
|
Empty "${var:SourceControl}"
|
|
|
|
|
}
|
|
|
|
|
False {
|
|
|
|
|
# the input selection is via ENUM, the possible types are
|
|
|
|
|
# Internal, Headset, Headphone and just 'Mic'
|
2026-01-13 16:41:35 +01:00
|
|
|
Macro.in.HDAMicEnum {
|
|
|
|
|
DevName "Mic:hda-int"
|
|
|
|
|
Comment "Internal Stereo Microphone"
|
|
|
|
|
Enum "Internal Mic"
|
|
|
|
|
Priority 100
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
2026-01-13 16:41:35 +01:00
|
|
|
Macro.hp.HDAMicEnum {
|
|
|
|
|
DevName "Mic:hda-hp"
|
|
|
|
|
Comment "Headphones Stereo Microphone"
|
|
|
|
|
Enum "Headphone Mic"
|
|
|
|
|
Priority 200
|
|
|
|
|
Jack "${var:MicHPJackControl}"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
2026-01-13 16:41:35 +01:00
|
|
|
Macro.mi.HDAMicEnum {
|
|
|
|
|
DevName "Mic:hda"
|
|
|
|
|
Comment "Stereo Microphone"
|
|
|
|
|
Enum "Mic"
|
|
|
|
|
Priority 300
|
|
|
|
|
Jack "${var:MicJackControl}"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
2026-01-13 16:41:35 +01:00
|
|
|
Macro.hs.HDAMicEnum {
|
|
|
|
|
DevName "Headset:hda-mic"
|
|
|
|
|
Comment "Headset Mono Microphone"
|
|
|
|
|
Enum "Headset Mic"
|
|
|
|
|
Priority 400
|
|
|
|
|
Jack "${var:MicHSJackControl}"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
|
|
|
|
}
|
2026-07-01 16:41:23 +02:00
|
|
|
True.If.autoswitch {
|
|
|
|
|
Condition {
|
|
|
|
|
Type ControlExists
|
|
|
|
|
Control "name='Internal Mic Boost Volume'"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
2026-07-01 16:41:23 +02:00
|
|
|
False {
|
|
|
|
|
# the input selection is via switches, the possible types are
|
|
|
|
|
# Mic and Front Mic
|
|
|
|
|
Macro.mic.HDAMicSwitch {
|
|
|
|
|
DevName "Mic:hda"
|
|
|
|
|
Comment "Stereo Microphone"
|
|
|
|
|
Name "Mic"
|
|
|
|
|
Priority 100
|
|
|
|
|
Jack "${var:MicJackControl}"
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
2026-07-01 16:41:23 +02:00
|
|
|
If.fmic {
|
|
|
|
|
Condition {
|
|
|
|
|
Type ControlExists
|
|
|
|
|
Control "name='Front Mic Playback Switch'"
|
|
|
|
|
}
|
|
|
|
|
True.Macro.fmic.HDAMicSwitch {
|
|
|
|
|
DevName "Mic:hda-front"
|
|
|
|
|
Comment "Front Stereo Microphone"
|
|
|
|
|
Name "Front Mic"
|
|
|
|
|
Priority 200
|
|
|
|
|
Jack "Front Mic Jack"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
True {
|
|
|
|
|
# third variant - the driver does auto-switching
|
|
|
|
|
# note that we should assign right Jack controls to
|
|
|
|
|
# allow expose the boost volume
|
|
|
|
|
Macro.mic.HDAMicSwitch {
|
|
|
|
|
DevName "Mic:hda-int"
|
|
|
|
|
Comment "Internal Stereo Microphone"
|
|
|
|
|
Name "Internal Mic"
|
|
|
|
|
Priority 100
|
|
|
|
|
}
|
|
|
|
|
If.mic {
|
|
|
|
|
# external microphone
|
|
|
|
|
Condition {
|
|
|
|
|
Type ControlExists
|
|
|
|
|
Control "name='Mic Boost Volume'"
|
|
|
|
|
}
|
|
|
|
|
True.Macro.mic.HDAMicSwitch {
|
|
|
|
|
DevName "Mic:hda"
|
|
|
|
|
Comment "Stereo Microphone"
|
|
|
|
|
Name "Mic"
|
|
|
|
|
Priority 200
|
|
|
|
|
Jack "${var:MicJackControl}"
|
|
|
|
|
}
|
ucm2: HDA: HiFi-analog/mic: Refactor the analog mic discovery
The current mic device creation works on certain machines and fails on
others. There are several places of conflicts and setups which can only
just fail, but this is mostly not an issue if the user never uses the mic,
only the speaker/headset - which, to be honest is what most of us do ;)
As an example:
The mic selection in most codecs are via enum and it is assumed to be
named 'Input Source', which is not always the case as some device uses
'Capture Source' for the control's name.
There is also different sets of mics that one can select from:
Exhibit A
numid=6,iface=MIXER,name='Input Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Headset Mic'
; Item #1 'Headphone Mic'
: values=1
Exhibit B
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
: values=0
Exhibit C
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Headset Mic'
; Item #2 'Headphone Mic'
: values=0
Exhibit D (this pushes the limits... The patch will ignore item 1)
numid=6,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Internal Mic'
; Item #1 'Internal Mic 1'
; Item #2 'Mic'
: values=2
Other issue is that we have this 'Headphone Mic', which turned out to be
a 'Stereo Microphone in Headphone Jack', so if it is selected then the
Headphone cannot work, they conflict, they use the same rings for different
direction and purpose.
This patch aims to make the mic discovery a bit more deterministic and
pragmatic.
But even if the UCM creates the use case profiles correctly, it is still
up to UIs (KDE/GNOME/etc) to misunderstand how UCM presents the profiles,
what they mean and most of all what 'Mic1', `Mic2', etc is.
KDE presents the profiles as they are and user can selct between them to
pick the right combination of output and input.
GNOME goes further with simplification (and fails with it) and presents
'random' Configuration profiles for Output and Input, plus a device
selection and they do work in an interesting way. GNOME also have popup
for specifying the type of the plugged accessory, which does not worl at
all with UCM profiles.
But, this patch is meant for a small step to have clear rules based mic
presentation for HDA.
The expectation is that what have worked will work as it used to and what
did not worked should be detected and presented correctly.
Closes: https://github.com/alsa-project/alsa-ucm-conf/pull/526
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2025-03-10 15:46:04 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|