alsa-ucm-conf/ucm2/HDA/HiFi-mic.conf

262 lines
6 KiB
Text
Raw Normal View History

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
# 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
# "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
#
# 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 ""
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 ""
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
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'"
}
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
}
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"
}
}
# 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
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
}
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
}
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"
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'
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
}
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
}
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
}
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
}
}
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
}
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
}
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
}
}
}
}