[alsa-devel] Correct macro for Headset widgets
What is the correct way to declare a Headset widget in a machine driver? I originally thought that by using SND_SOC_DAPM_HP macro was enough, but it's not since the headset is both headphones and microphone.
In my machine driver I have the following widget and map for headset:
SND_SOC_DAPM_HP("Headset Jack", NULL)
...
/* Headset: HSMIC (with bias), HSOL, HSOR */ {"Headset Jack", NULL, "HSOL"}, {"Headset Jack", NULL, "HSOR"}, {"HSMIC", NULL, "Headset Mic Bias"}, {"Headset Mic Bias", NULL, "Headset Jack"},
but the "Headset Mic Bias" widget never gets powered when the "Headset Jack" pin is enabled.
When the audio map is scanned, only valid routes are powered: DAC-Output, Input-DAC, Input-Output, DAC-ADC. And "Headset Jack" (declared as SND_SOC_DAPM_HP) is not a valid input endpoint, then the capture route becomes invalid.
Can we have a macro specifically for Headset widgets?
Thanks, -Misa
On Tue, Mar 17, 2009 at 08:31:55PM -0500, Lopez Cruz, Misael wrote:
What is the correct way to declare a Headset widget in a machine driver? I originally thought that by using SND_SOC_DAPM_HP macro was enough, but it's not since the headset is both headphones and microphone.
Declare separate microphone and headphone widgets ("Headset Microphone" and "Headset Headphone" or something). While physically they're on the same device as far as the audio routing of the codec is concerned they are separate devices - there's no direct electrical interconnection between the input and output side.
Can we have a macro specifically for Headset widgets?
If we had a single macro then it'd need to expand to the two separate widgets - we could do that but I'm not sure it'd add much to usability since the routes would end up not linking to widgets that were directly specified in the code.
participants (2)
-
Lopez Cruz, Misael -
Mark Brown