[PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

[PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

[Steven 'Steve' Kendall]

On some models like the Dell Inspiron 15 3520, jack
detection does not work. This patch switches to polling
and more regularly queries the lower values rather
than cached values for the headphone and mic jacks.
It also includes some logic to prevent the polling
while headphones are already plugged so no
audible "tick" can be heard.

---
This patch switches to a polling method for a
specific Dell machine (Inspiron 15 3520). This fixes
jack detection for this model. It's possible the gate
on manufacturer and model are unnecessary and this problem
is common to a wider set of machines, but I've only tested
on one machine thus far. I left the other logic ungated
as it seemed likely the cache was not providing up-to-date
information broadly. But I'm open to gating more or less
of the content or changing the approach entirely.

Signed-off-by: Steven 'Steve' Kendall <skend@chromium.org>
---
 sound/hda/codecs/cirrus/cs8409.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/sound/hda/codecs/cirrus/cs8409.c b/sound/hda/codecs/cirrus/cs8409.c
index c43ff3ef75b6e..733234844e7df 100644
--- a/sound/hda/codecs/cirrus/cs8409.c
+++ b/sound/hda/codecs/cirrus/cs8409.c
@@ -766,6 +766,9 @@ static int cs42l42_handle_tip_sense(struct sub_codec *cs42l42, unsigned int reg_
 	/* TIP_SENSE INSERT/REMOVE */
 	switch (reg_ts_status) {
 	case CS42L42_TS_PLUG:
+		// if jack is already plugged, ignore plug event
+		if (cs42l42->hp_jack_in)
+			break;
 		if (cs42l42->no_type_dect) {
 			status_changed = 1;
 			cs42l42->hp_jack_in = 1;
@@ -776,6 +779,9 @@ static int cs42l42_handle_tip_sense(struct sub_codec *cs42l42, unsigned int reg_
 		break;
 
 	case CS42L42_TS_UNPLUG:
+		// if jack is already unplugged, ignore unplug event
+		if (!cs42l42->hp_jack_in && !cs42l42->mic_jack_in)
+			break;
 		status_changed = 1;
 		cs42l42->hp_jack_in = 0;
 		cs42l42->mic_jack_in = 0;
@@ -1092,12 +1098,14 @@ static int cs8409_cs42l42_exec_verb(struct hdac_device *dev, unsigned int cmd, u
 	switch (nid) {
 	case CS8409_CS42L42_HP_PIN_NID:
 		if (verb == AC_VERB_GET_PIN_SENSE) {
+			cs42l42_jack_unsol_event(cs42l42);
 			*res = (cs42l42->hp_jack_in) ? AC_PINSENSE_PRESENCE : 0;
 			return 0;
 		}
 		break;
 	case CS8409_CS42L42_AMIC_PIN_NID:
 		if (verb == AC_VERB_GET_PIN_SENSE) {
+			cs42l42_jack_unsol_event(cs42l42);
 			*res = (cs42l42->mic_jack_in) ? AC_PINSENSE_PRESENCE : 0;
 			return 0;
 		}
@@ -1157,6 +1165,11 @@ void cs8409_cs42l42_fixups(struct hda_codec *codec, const struct hda_fixup *fix,
 		case CS8409_WARLOCK_MLK_DUAL_MIC:
 			spec->scodecs[CS8409_CODEC0]->full_scale_vol = CS42L42_FULL_SCALE_VOL_0DB;
 			spec->speaker_pdn_gpio = CS8409_WARLOCK_SPEAKER_PDN;
+			// if Dell Inspiron 15 3520, poll jack at 250ms
+			if (codec->bus->pci->subsystem_vendor == 0x1028 &&
+			    codec->bus->pci->subsystem_device == 0x0bb2) {
+				codec->jackpoll_interval = msecs_to_jiffies(250);
+			}
 			break;
 		default:
 			spec->scodecs[CS8409_CODEC0]->full_scale_vol =
@@ -1208,8 +1221,10 @@ void cs8409_cs42l42_fixups(struct hda_codec *codec, const struct hda_fixup *fix,
 		 * Run immediately after init.
 		 */
 		if (spec->init_done && spec->build_ctrl_done
-			&& !spec->scodecs[CS8409_CODEC0]->hp_jack_in)
+			&& !spec->scodecs[CS8409_CODEC0]->hp_jack_in) {
 			cs42l42_run_jack_detect(spec->scodecs[CS8409_CODEC0]);
+			cs42l42_enable_jack_detect(spec->scodecs[CS8409_CODEC0]);
+		}
 		break;
 	default:
 		break;

---
base-commit: d96fcfe1b7f94ac742984ae7986b94a116abff1b
change-id: 20260710-fix-headphone-plug-cirrus-dell-5e3b49da5f52

Best regards,
-- 
Steven 'Steve' Kendall <skend@chromium.org>

Re: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

[Takashi Iwai]

On Mon, 13 Jul 2026 23:21:41 +0200,
Steven 'Steve' Kendall wrote:
> 
> On some models like the Dell Inspiron 15 3520, jack
> detection does not work. This patch switches to polling
> and more regularly queries the lower values rather
> than cached values for the headphone and mic jacks.
> It also includes some logic to prevent the polling
> while headphones are already plugged so no
> audible "tick" can be heard.
> 
> ---

This makes the remaining text not taken by git-am.
And, I guess the text above should have been combined with the below?

> This patch switches to a polling method for a
> specific Dell machine (Inspiron 15 3520). This fixes
> jack detection for this model. It's possible the gate
> on manufacturer and model are unnecessary and this problem
> is common to a wider set of machines, but I've only tested
> on one machine thus far. I left the other logic ungated
> as it seemed likely the cache was not providing up-to-date
> information broadly. But I'm open to gating more or less
> of the content or changing the approach entirely.

The jack polling is really the last resort, and I'd like to know why
the normal jack detection doesn't work at first.  Is it the missing
unsol event?  Or the jack detection itself doesn't work?
If it's a missing unsol event, this drop happens always?  Or on
certain runtime PM state?


thanks,

Takashi

> 
> Signed-off-by: Steven 'Steve' Kendall <skend@chromium.org>
> ---
>  sound/hda/codecs/cirrus/cs8409.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/hda/codecs/cirrus/cs8409.c b/sound/hda/codecs/cirrus/cs8409.c
> index c43ff3ef75b6e..733234844e7df 100644
> --- a/sound/hda/codecs/cirrus/cs8409.c
> +++ b/sound/hda/codecs/cirrus/cs8409.c
> @@ -766,6 +766,9 @@ static int cs42l42_handle_tip_sense(struct sub_codec *cs42l42, unsigned int reg_
>  	/* TIP_SENSE INSERT/REMOVE */
>  	switch (reg_ts_status) {
>  	case CS42L42_TS_PLUG:
> +		// if jack is already plugged, ignore plug event
> +		if (cs42l42->hp_jack_in)
> +			break;
>  		if (cs42l42->no_type_dect) {
>  			status_changed = 1;
>  			cs42l42->hp_jack_in = 1;
> @@ -776,6 +779,9 @@ static int cs42l42_handle_tip_sense(struct sub_codec *cs42l42, unsigned int reg_
>  		break;
>  
>  	case CS42L42_TS_UNPLUG:
> +		// if jack is already unplugged, ignore unplug event
> +		if (!cs42l42->hp_jack_in && !cs42l42->mic_jack_in)
> +			break;
>  		status_changed = 1;
>  		cs42l42->hp_jack_in = 0;
>  		cs42l42->mic_jack_in = 0;
> @@ -1092,12 +1098,14 @@ static int cs8409_cs42l42_exec_verb(struct hdac_device *dev, unsigned int cmd, u
>  	switch (nid) {
>  	case CS8409_CS42L42_HP_PIN_NID:
>  		if (verb == AC_VERB_GET_PIN_SENSE) {
> +			cs42l42_jack_unsol_event(cs42l42);
>  			*res = (cs42l42->hp_jack_in) ? AC_PINSENSE_PRESENCE : 0;
>  			return 0;
>  		}
>  		break;
>  	case CS8409_CS42L42_AMIC_PIN_NID:
>  		if (verb == AC_VERB_GET_PIN_SENSE) {
> +			cs42l42_jack_unsol_event(cs42l42);
>  			*res = (cs42l42->mic_jack_in) ? AC_PINSENSE_PRESENCE : 0;
>  			return 0;
>  		}
> @@ -1157,6 +1165,11 @@ void cs8409_cs42l42_fixups(struct hda_codec *codec, const struct hda_fixup *fix,
>  		case CS8409_WARLOCK_MLK_DUAL_MIC:
>  			spec->scodecs[CS8409_CODEC0]->full_scale_vol = CS42L42_FULL_SCALE_VOL_0DB;
>  			spec->speaker_pdn_gpio = CS8409_WARLOCK_SPEAKER_PDN;
> +			// if Dell Inspiron 15 3520, poll jack at 250ms
> +			if (codec->bus->pci->subsystem_vendor == 0x1028 &&
> +			    codec->bus->pci->subsystem_device == 0x0bb2) {
> +				codec->jackpoll_interval = msecs_to_jiffies(250);
> +			}
>  			break;
>  		default:
>  			spec->scodecs[CS8409_CODEC0]->full_scale_vol =
> @@ -1208,8 +1221,10 @@ void cs8409_cs42l42_fixups(struct hda_codec *codec, const struct hda_fixup *fix,
>  		 * Run immediately after init.
>  		 */
>  		if (spec->init_done && spec->build_ctrl_done
> -			&& !spec->scodecs[CS8409_CODEC0]->hp_jack_in)
> +			&& !spec->scodecs[CS8409_CODEC0]->hp_jack_in) {
>  			cs42l42_run_jack_detect(spec->scodecs[CS8409_CODEC0]);
> +			cs42l42_enable_jack_detect(spec->scodecs[CS8409_CODEC0]);
> +		}
>  		break;
>  	default:
>  		break;
> 
> ---
> base-commit: d96fcfe1b7f94ac742984ae7986b94a116abff1b
> change-id: 20260710-fix-headphone-plug-cirrus-dell-5e3b49da5f52
> 
> Best regards,
> -- 
> Steven 'Steve' Kendall <skend@chromium.org>
> 

Re: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

[Steven Kendall]

> This makes the remaining text not taken by git-am.
> And, I guess the text above should have been combined with the below?

Sorry about that! I'm using b4 and that was the result of having a
cover letter in addition to the commit.

> The jack polling is really the last resort, and I'd like to know why
> the normal jack detection doesn't work at first.  Is it the missing
> unsol event?  Or the jack detection itself doesn't work?
> If it's a missing unsol event, this drop happens always?  Or on
> certain runtime PM state?

In my debugging output I could never get the unsol event to trigger.
I'm not sure if that's the same as jack detection not working. I tried
a few timing changes and pin changes but to no effect. From the user's
perspective, audio plays both from the headphones and the speakers
when headphones are plugged in. According to my notes, I also observed
this on Ubuntu 22.04  LTS on its initial image, but applying its
latest update resolved the issue. One notable clue is that currently
on Chrome OS (with no patch), sleeping and resuming the machine does
fix jack detection, but I've been unable to fix initial boot behavior
thus far besides an approach like the patch here.

Re: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

[Takashi Iwai]

On Tue, 14 Jul 2026 21:51:21 +0200,
Steven Kendall wrote:
> 
> > This makes the remaining text not taken by git-am.
> > And, I guess the text above should have been combined with the below?
> 
> Sorry about that! I'm using b4 and that was the result of having a
> cover letter in addition to the commit.

If you want to give additional comments that shouldn't be included in
the commit log, put it under '---' line, instead.  Then it'll be cut
off.

> > The jack polling is really the last resort, and I'd like to know why
> > the normal jack detection doesn't work at first.  Is it the missing
> > unsol event?  Or the jack detection itself doesn't work?
> > If it's a missing unsol event, this drop happens always?  Or on
> > certain runtime PM state?
> 
> In my debugging output I could never get the unsol event to trigger.
> I'm not sure if that's the same as jack detection not working. I tried
> a few timing changes and pin changes but to no effect. From the user's
> perspective, audio plays both from the headphones and the speakers
> when headphones are plugged in. According to my notes, I also observed
> this on Ubuntu 22.04  LTS on its initial image, but applying its
> latest update resolved the issue. One notable clue is that currently
> on Chrome OS (with no patch), sleeping and resuming the machine does
> fix jack detection, but I've been unable to fix initial boot behavior
> thus far besides an approach like the patch here.

Have you tried to turn off the runtime PM for HD-audio?
The question is whether the unsol event doesn't work *at all*, or it
just stops when the codec (or the controller) is powered down.
Also, CS8409 driver enables the per-node power-save feature, and this
might influence, too.


Takashi

Re: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

[Steven Kendall]

 > Have you tried to turn off the runtime PM for HD-audio?
> The question is whether the unsol event doesn't work *at all*, or it
> just stops when the codec (or the controller) is powered down.
> Also, CS8409 driver enables the per-node power-save feature, and this
> might influence, too.

I tried this before (disabling power management) and didn't see any
success and just tried it two ways now:
adding a segment in sound/hda/controllers/intel.c like

@@ -2306,6 +2306,8 @@ static const struct snd_pci_quirk
power_save_denylist[] = {
        SND_PCI_QUIRK(0x1028, 0x0962, "Dell ALC3271", 0),
        /* https://bugzilla.kernel.org/show_bug.cgi?id=220210 */
        SND_PCI_QUIRK(0x17aa, 0x5079, "Lenovo Thinkpad E15", 0),
+       /* Dell CS8409 Warlock MLK */
+       SND_PCI_QUIRK(0x1028, 0x0bb2, "Dell CS8409 Warlock MLK", 0),
        {}
 };

and adding a segment in sound/hda/codecs/cirrus/cs8409.c like

@@ -1606,6 +1607,13 @@ static int cs8409_probe(struct hda_codec
*codec, const struct hda_device_id *id)
        }

        snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_PROBE);
+
+       if (codec->bus->pci->subsystem_vendor == 0x1028 &&
+           codec->bus->pci->subsystem_device == 0x0bb2) {
+               pm_runtime_get_noresume(&codec->core.dev);
+               pm_runtime_forbid(&codec->core.dev);
+       }
+
        return 0;
 }

I debug logs showing both these firing and
/sys/module/snd_hda_intel/parameters/power_save reads as 0. However
with either or both of these changes applied the plug events are still
not detected on first boot, and the "fix" of closing the lid and
opening it again still restores jack detection on Chrome OS.

Re: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

[Stefan Binding]

Hi,

I have some concerns about this patch.
The original design on the driver relies on 2 different interrupts, one for Jack Detect, and one for Type Detect.
I am concerned that these changes either prevent the interrupts from being enabled at the right time, or enable them at the wrong time, and possibly simultaneously.

I believe we may have one of these laptops ourselves, so we might be able to have a look ourselves, though it may take a few weeks for us to do this.
Can you tell us which OS you are using to test this? This was originally tested on Ubuntu, but I think this is ChromeOS you are testing on?

Thanks,

Stefan

On 13/07/2026 22:21, Steven 'Steve' Kendall wrote:
> On some models like the Dell Inspiron 15 3520, jack
> detection does not work. This patch switches to polling
> and more regularly queries the lower values rather
> than cached values for the headphone and mic jacks.
> It also includes some logic to prevent the polling
> while headphones are already plugged so no
> audible "tick" can be heard.
>
> ---
> This patch switches to a polling method for a
> specific Dell machine (Inspiron 15 3520). This fixes
> jack detection for this model. It's possible the gate
> on manufacturer and model are unnecessary and this problem
> is common to a wider set of machines, but I've only tested
> on one machine thus far. I left the other logic ungated
> as it seemed likely the cache was not providing up-to-date
> information broadly. But I'm open to gating more or less
> of the content or changing the approach entirely.
>
> Signed-off-by: Steven 'Steve' Kendall <skend@chromium.org>
> ---
>  sound/hda/codecs/cirrus/cs8409.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/sound/hda/codecs/cirrus/cs8409.c 
> b/sound/hda/codecs/cirrus/cs8409.c
> index c43ff3ef75b6e..733234844e7df 100644
> --- a/sound/hda/codecs/cirrus/cs8409.c
> +++ b/sound/hda/codecs/cirrus/cs8409.c
> @@ -766,6 +766,9 @@ static int cs42l42_handle_tip_sense(struct sub_codec 
> *cs42l42, unsigned int reg_
>  	/* TIP_SENSE INSERT/REMOVE */
>  	switch (reg_ts_status) {
>  	case CS42L42_TS_PLUG:
> +		// if jack is already plugged, ignore plug event
> +		if (cs42l42->hp_jack_in)
> +			break;
>  		if (cs42l42->no_type_dect) {
>  			status_changed = 1;
>  			cs42l42->hp_jack_in = 1;
> @@ -776,6 +779,9 @@ static int cs42l42_handle_tip_sense(struct sub_codec 
> *cs42l42, unsigned int reg_
>  		break;
>
>  	case CS42L42_TS_UNPLUG:
> +		// if jack is already unplugged, ignore unplug event
> +		if (!cs42l42->hp_jack_in && !cs42l42->mic_jack_in)
> +			break;
>  		status_changed = 1;
>  		cs42l42->hp_jack_in = 0;
>  		cs42l42->mic_jack_in = 0;
> @@ -1092,12 +1098,14 @@ static int cs8409_cs42l42_exec_verb(struct 
> hdac_device *dev, unsigned int cmd, u
>  	switch (nid) {
>  	case CS8409_CS42L42_HP_PIN_NID:
>  		if (verb == AC_VERB_GET_PIN_SENSE) {
> +			cs42l42_jack_unsol_event(cs42l42);
>  			*res = (cs42l42->hp_jack_in) ? AC_PINSENSE_PRESENCE : 0;
>  			return 0;
>  		}
>  		break;
>  	case CS8409_CS42L42_AMIC_PIN_NID:
>  		if (verb == AC_VERB_GET_PIN_SENSE) {
> +			cs42l42_jack_unsol_event(cs42l42);
>  			*res = (cs42l42->mic_jack_in) ? AC_PINSENSE_PRESENCE : 0;
>  			return 0;
>  		}
> @@ -1157,6 +1165,11 @@ void cs8409_cs42l42_fixups(struct hda_codec *codec, 
> const struct hda_fixup *fix,
>  		case CS8409_WARLOCK_MLK_DUAL_MIC:
>  			spec->scodecs[CS8409_CODEC0]->full_scale_vol = 
> CS42L42_FULL_SCALE_VOL_0DB;
>  			spec->speaker_pdn_gpio = CS8409_WARLOCK_SPEAKER_PDN;
> +			// if Dell Inspiron 15 3520, poll jack at 250ms
> +			if (codec->bus->pci->subsystem_vendor == 0x1028 &&
> +			    codec->bus->pci->subsystem_device == 0x0bb2) {
> +				codec->jackpoll_interval = msecs_to_jiffies(250);
> +			}
>  			break;
>  		default:
>  			spec->scodecs[CS8409_CODEC0]->full_scale_vol =
> @@ -1208,8 +1221,10 @@ void cs8409_cs42l42_fixups(struct hda_codec *codec, 
> const struct hda_fixup *fix,
>  		 * Run immediately after init.
>  		 */
>  		if (spec->init_done && spec->build_ctrl_done
> -			&& !spec->scodecs[CS8409_CODEC0]->hp_jack_in)
> +			&& !spec->scodecs[CS8409_CODEC0]->hp_jack_in) {
>  			cs42l42_run_jack_detect(spec->scodecs[CS8409_CODEC0]);
> +			cs42l42_enable_jack_detect(spec->scodecs[CS8409_CODEC0]);
> +		}
>  		break;
>  	default:
>  		break;
>
> ---
> base-commit: d96fcfe1b7f94ac742984ae7986b94a116abff1b
> change-id: 20260710-fix-headphone-plug-cirrus-dell-5e3b49da5f52
>
> Best regards,

Re: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

[Steven Kendall]

> The original design on the driver relies on 2 different interrupts, one for Jack Detect, and one for Type Detect.
> I am concerned that these changes either prevent the interrupts from being enabled at the right time, or enable them at the wrong time, and possibly simultaneously.

Thanks for the info. I had trouble getting these interrupts to fire on
this machine. Have any advice for getting unsol events to fire? I
tried a few things but wasn't able to trigger any and resorted to
polling.

> I believe we may have one of these laptops ourselves, so we might be able to have a look ourselves, though it may take a few weeks for us to do this.
> Can you tell us which OS you are using to test this? This was originally tested on Ubuntu, but I think this is ChromeOS you are testing on?

That would be great! A few weeks wouldn't be an issue for us. I've
tested this on Chrome OS (Chrome OS Flex, specifically) but I also
noticed some odd behavior on Ubuntu even though everything more or
less worked there. Alsa wasn't reading the jack state as
plugged/unplugged until audio played. I'm not sure if that's by
design. I wasn't sure if Ubuntu had some additional kernel patches I
couldn't find; I was using their LTS HWE branch and when deployed on
Chrome OS I didn't see any change in behavior.

Re: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

[Stefan Binding]

Hi,

On 14/07/2026 20:26, Steven Kendall wrote:
>> The original design on the driver relies on 2 different interrupts, one for Jack Detect, and one for Type Detect.
>> I am concerned that these changes either prevent the interrupts from being enabled at the right time, or enable them at the wrong time, and possibly simultaneously.
> Thanks for the info. I had trouble getting these interrupts to fire on
> this machine. Have any advice for getting unsol events to fire? I
> tried a few things but wasn't able to trigger any and resorted to
> polling.

The interrupts not firing is very interesting. To give some background information on how the driver is intended to work:

There are 2 types of interrupts that the CS42L42 is configured to fire in this driver. The first is for Jack Plug/Unplug detection
(which is enabled by the call to cs42l42_enable_jack_detect()), and the second is for Jack Type detection
(enabled by the call to cs42l42_run_jack_detect()). The call to the second function disabled the interrupt of the first.

The intended flow for the driver is that when the system is initialised and resumed, the Jack Plug/Unplug interrupt is enabled,
and thus if a jack is plugged or unplugged the interrupt fires, and upon plug, the driver then runs Jack Type detection.
Eventually this calls snd_hda_jack_unsol_event() which informs the HDA core.

The Plug/Unplug interrupt will only fire on Plug/Unplug, whereas the Type Detection interrupt will always fire, regardless if where a jack is inserted.

This is why, after initialisation, the driver calls cs42l42_run_jack_detect(), to check the jack state after boot (since the plug interrupt could not have occurred).

Similarly, we also do the same upon resume. We could never get the codec wake to work properly, so whilst the driver is suspended, the codec is asleep,
and the plug/unplug interrupt will not fire, and therefore will not wake the system. If you are expecting to see interrupts occurring whilst suspended,
you will not see any. Instead, when audio starts and the driver is resumed, type detection is run immediately, which switches the Jack at that time.

On Ubuntu, the driver is resumed when you go the Sound settings menu, so you can see the interrupts firing when you insert or remove the jack.
I am unsure if ChromeOS does the same. Alternatively, playing audio will resume the driver and the interrupts should fire upon jack plug/unplug.
Inserting or removing the jack whilst suspended will not result in any interrupts until the driver is resumed (either by playback or by opening the setting menu in Ubuntu).

Thanks,

Stefan

>
>> I believe we may have one of these laptops ourselves, so we might be able to have a look ourselves, though it may take a few weeks for us to do this.
>> Can you tell us which OS you are using to test this? This was originally tested on Ubuntu, but I think this is ChromeOS you are testing on?
> That would be great! A few weeks wouldn't be an issue for us. I've
> tested this on Chrome OS (Chrome OS Flex, specifically) but I also
> noticed some odd behavior on Ubuntu even though everything more or
> less worked there. Alsa wasn't reading the jack state as
> plugged/unplugged until audio played. I'm not sure if that's by
> design. I wasn't sure if Ubuntu had some additional kernel patches I
> couldn't find; I was using their LTS HWE branch and when deployed on
> Chrome OS I didn't see any change in behavior.
>