January 2018 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] BUG: unable to handle kernel paging request in memset_erms
by syzbot 05 Jan '18

05 Jan '18

Hello, syzkaller hit the following crash on 30a7acd573899fd8b8ac39236eff6468b195ac7d git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master compiler: gcc (GCC) 7.1.1 20170620 .config is attached Raw console output is attached. Unfortunately, I don't have any reproducer for this bug yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+3902b5220e8ca27889ca(a)syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer. BUG: unable to handle kernel paging request at ffffc90006002000 IP: memset_erms+0x9/0x10 arch/x86/lib/memset_64.S:65 PGD 1dad2c067 P4D 1dad2c067 PUD 1dad2d067 PMD 192fc9067 PTE 0 Oops: 0002 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 13106 Comm: syz-executor6 Not tainted 4.15.0-rc6+ #245 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:memset_erms+0x9/0x10 arch/x86/lib/memset_64.S:65 RSP: 0018:ffff8801bfc57508 EFLAGS: 00010246 RAX: fffff52000c2a800 RBX: ffffc90006000000 RCX: 0000000000152000 RDX: 0000000000154000 RSI: 0000000000000000 RDI: ffffc90006002000 RBP: ffff8801bfc57528 R08: 0000000000000000 R09: ffffc90006000000 R10: 000000000002a800 R11: fffff52000c2a7ff R12: 0000000000154000 R13: 0000000000000000 R14: ffffffff86e6625c R15: 0000000000000010 FS: 00007fa978f9e700(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90006002000 CR3: 00000001cb3c0006 CR4: 00000000001606e0 DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: memset include/linux/string.h:329 [inline] snd_pcm_format_set_silence+0x13f/0x4b0 sound/core/pcm_misc.c:414 loopback_prepare+0xcdc/0x1000 sound/drivers/aloop.c:356 snd_pcm_do_prepare+0x58/0x90 sound/core/pcm_native.c:1640 snd_pcm_action_single+0x70/0x110 sound/core/pcm_native.c:1084 snd_pcm_action_nonatomic+0x95/0xa0 sound/core/pcm_native.c:1151 snd_pcm_prepare+0x115/0x1a0 sound/core/pcm_native.c:1687 snd_pcm_kernel_ioctl+0x97/0x240 sound/core/pcm_native.c:2993 snd_pcm_oss_prepare+0x49/0x150 sound/core/oss/pcm_oss.c:1105 snd_pcm_oss_make_ready+0xf9/0x130 sound/core/oss/pcm_oss.c:1133 snd_pcm_oss_set_trigger+0x62d/0x830 sound/core/oss/pcm_oss.c:1944 snd_pcm_oss_poll+0x77c/0xd20 sound/core/oss/pcm_oss.c:2712 do_pollfd fs/select.c:822 [inline] do_poll fs/select.c:872 [inline] do_sys_poll+0x715/0x10b0 fs/select.c:966 SYSC_poll fs/select.c:1024 [inline] SyS_poll+0x10d/0x450 fs/select.c:1012 entry_SYSCALL_64_fastpath+0x23/0x9a RIP: 0033:0x452ac9 RSP: 002b:00007fa978f9dc58 EFLAGS: 00000212 ORIG_RAX: 0000000000000007 RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452ac9 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000020038000 RBP: 000000000000030f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f2a08 R13: 00000000ffffffff R14: 00007fa978f9e6d4 R15: 0000000000000000 Code: 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 RIP: memset_erms+0x9/0x10 arch/x86/lib/memset_64.S:65 RSP: ffff8801bfc57508 CR2: ffffc90006002000 ---[ end trace 64150ed1bb325dd0 ]--- --- This bug is generated by a dumb bot. It may contain errors. See https://goo.gl/tpsmEJ for details. Direct all questions to syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. If you forgot to add the Reported-by tag, once the fix for this bug is merged into any tree, please reply to this email with: #syz fix: exact-commit-title To mark this as a duplicate of another syzbot report, please reply with: #syz dup: exact-subject-of-another-report If it's a one-off invalid bug report, please reply with: #syz invalid Note: if the crash happens again, it will cause creation of a new bug report. Note: all commands must start from beginning of the line in the email body.

1 1

[alsa-devel] Sync issues with newer Roland and Boss devices
by Oliver Friedrich 05 Jan '18

05 Jan '18

Dear Alsa-angels, I hope I'm posting this to the right place. I was not able to get my BOSS GT-1 running: - uname -r 4.14.11-1-ARCH (occured on 4.14.10 as well) - dmesg ... usb 2-1: Unable to change format on ep #8e: already in use ... - aplay -l Karte 2: GT1 [GT-1], Gerät 0: USB Audio [USB Audio] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 lsusb output attached I found a dirty workaround there: https://www.linuxmusicians.com/viewtopic.php?f=6&t=17180&start=30#p83949 I added the USB ID of my device and it works (ALSA, PulseAudio, JACK). This seems to work for the RC-300 loopstation and the Micro BR-80, too. The affected code was changed with commit ba7c2be114243fa4cfcbc66a81db18e1d55abf4b about 4 years ago. I only applied a simple patch without knowing what the reason for the other Roland quirks were, so I just wanted to inform you about this issue. I'm not sure what's missing at the moment, I'm no kernel developer (yet). Thanks in advance! If you need more info, just tell me. Regards Oli

1 0

[alsa-devel] [PATCH v1 0/6] add "simple-mfd" support for MediaTek audio subsystem
by Ryder Lee 04 Jan '18

04 Jan '18

Hi, The reason for this series is that MediaTek audio hardware block expose more than a single functionality, but register those in different kernel subsystems. Same issue could also be found in MMSYS: https://lkml.org/lkml/2017/11/14/669 Hence use "simple-mfd" to handle this kind of situation, that will make sure all children are registered - and we don't need to write an MFD driver specially. It was tested on the bananapi-r2 and the MT2701/MT7622 EVB. [1]~[3]: modify the current audio driver accordingly. [5][6]: add clock driver for MT2701 and add missing data for MT7622. changes since v1: - To avoid writing an MFD driver, we add "simple-mfd" in the audsys binding. - Move three top clocks to audio driver [1] as we remove mfd/mtk-audsys.c in v1. Ryder Lee (6): ASoC: mediatek: add some core clocks for MT2701 AFE ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device ASoC: mediatek: update MT2701 AFE documentation to adapt mfd device dt-bindings: clock: mediatek: add "simple-mfd" in audsys documentation clk: mediatek: update missing clock data for MT7622 audsys clk: mediatek: add audsys support for MT2701 .../bindings/arm/mediatek/mediatek,audsys.txt | 21 ++- .../devicetree/bindings/sound/mt2701-afe-pcm.txt | 171 +++++++++++--------- drivers/clk/mediatek/Kconfig | 6 + drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt2701-aud.c | 174 +++++++++++++++++++++ drivers/clk/mediatek/clk-mt7622-aud.c | 3 +- include/dt-bindings/clock/mt7622-clk.h | 3 +- sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c | 30 +++- sound/soc/mediatek/mt2701/mt2701-afe-common.h | 3 + sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 45 +++--- sound/soc/mediatek/mt2701/mt2701-reg.h | 1 - 11 files changed, 345 insertions(+), 113 deletions(-) create mode 100644 drivers/clk/mediatek/clk-mt2701-aud.c -- 1.9.1

2 6

[alsa-devel] [V3 1/2] dt-bindings: Added device tree binding for max98373 amplifier
by Ryan Lee 04 Jan '18

04 Jan '18

Signed-off-by: Ryan Lee <ryans.lee(a)maximintegrated.com> --- Changes since v2: * Splitted dt bindings to the separated patch * Changed 'interelave-mode' device property from u32 to boolean .../devicetree/bindings/sound/max98373.txt | 40 ++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/max98373.txt diff --git a/Documentation/devicetree/bindings/sound/max98373.txt b/Documentation/devicetree/bindings/sound/max98373.txt new file mode 100644 index 0000000..456cb1c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/max98373.txt @@ -0,0 +1,40 @@ +Maxim Integrated MAX98373 Speaker Amplifier + +This device supports I2C. + +Required properties: + + - compatible : "maxim,max98373" + + - reg : the I2C address of the device. + +Optional properties: + + - maxim,vmon-slot-no : slot number used to send voltage information + or in inteleave mode this will be used as + interleave slot. + slot range : 0 ~ 15, Default : 0 + + - maxim,imon-slot-no : slot number used to send current information + slot range : 0 ~ 15, Default : 0 + + - maxim,spkfb-slot-no : slot number used to send speaker feedback information + slot range : 0 ~ 15, Default : 0 + + - maxim,interleave-mode : For cases where a single combined channel + for the I/V sense data is not sufficient, the device can also be configured + to share a single data output channel on alternating frames. + In this configuration, the current and voltage data will be frame interleaved + on a single output channel. + Boolean, define to enable the interleave mode, Default : false + +Example: + +codec: max98373@31 { + compatible = "maxim,max98373"; + reg = <0x31>; + maxim,vmon-slot-no = <0>; + maxim,imon-slot-no = <1>; + maxim,spkfb-slot-no = <2>; + maxim,interleave-mode; +}; -- 2.7.4

2 1

[alsa-devel] [PATCH] ASoC: simple-card: Pass 'reg' property in the examples
by Fabio Estevam 04 Jan '18

04 Jan '18

From: Fabio Estevam <fabio.estevam(a)nxp.com> Since unit addresses are passed to simple-audio-card,dai-link a corresponding 'reg' property is needed, otherwise dtc complains (when building with W=1) in case someone copies the bindings example into a real dts file: Warning (unit_address_vs_reg): Node /sound-digital/simple-audio-card,dai-link@0 has a unit name, but no reg property Improve the example by passing the correct 'reg' properties. Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com> --- Documentation/devicetree/bindings/sound/simple-card.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index 166f229..17c13e7 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -140,6 +140,7 @@ sound { simple-audio-card,name = "Cubox Audio"; simple-audio-card,dai-link@0 { /* I2S - HDMI */ + reg = <0>; format = "i2s"; cpu { sound-dai = <&audio1 0>; @@ -150,6 +151,7 @@ sound { }; simple-audio-card,dai-link@1 { /* S/PDIF - HDMI */ + reg = <1>; cpu { sound-dai = <&audio1 1>; }; @@ -159,6 +161,7 @@ sound { }; simple-audio-card,dai-link@2 { /* S/PDIF - S/PDIF */ + reg = <2>; cpu { sound-dai = <&audio1 1>; }; -- 2.7.4

2 1

[alsa-devel] [PATCH] ALSA: pcm: Workaround for weird PulseAudio behavior on rewind error
by Takashi Iwai 04 Jan '18

04 Jan '18

The commit 9027c4639ef1 ("ALSA: pcm: Call ack() whenever appl_ptr is updated") introduced the possible error code returned from the PCM rewind ioctl. Basically the change was for handling the indirect PCM more correctly, but ironically, it caused rather a side-effect: PulseAudio gets pissed off when receiving an error from rewind, throws everything away and stops processing further, resulting in the silence. It's clearly a failure in the application side, so the best would be to fix that bug in PA. OTOH, PA is mostly the only user of the rewind feature, so it's not good to slap the sole customer. This patch tries to mitigate the situation: instead of returning an error, now the rewind ioctl returns zero when the driver can't rewind. It indicates that no rewind was performed, so the behavior is consistent, at least. Fixes: 9027c4639ef1 ("ALSA: pcm: Call ack() whenever appl_ptr is updated") Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/pcm_native.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index a4d92e46c459..f08772568c17 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -2580,7 +2580,7 @@ static snd_pcm_sframes_t forward_appl_ptr(struct snd_pcm_substream *substream, return ret < 0 ? ret : frames; } -/* decrease the appl_ptr; returns the processed frames or a negative error */ +/* decrease the appl_ptr; returns the processed frames or zero for error */ static snd_pcm_sframes_t rewind_appl_ptr(struct snd_pcm_substream *substream, snd_pcm_uframes_t frames, snd_pcm_sframes_t avail) @@ -2597,7 +2597,12 @@ static snd_pcm_sframes_t rewind_appl_ptr(struct snd_pcm_substream *substream, if (appl_ptr < 0) appl_ptr += runtime->boundary; ret = pcm_lib_apply_appl_ptr(substream, appl_ptr); - return ret < 0 ? ret : frames; + /* NOTE: we return zero for errors because PulseAudio gets depressed + * upon receiving an error from rewind ioctl and stops processing + * any longer. Returning zero means that no rewind is done, so + * it's not absolutely wrong to answer like that. + */ + return ret < 0 ? 0 : frames; } static snd_pcm_sframes_t snd_pcm_playback_rewind(struct snd_pcm_substream *substream, -- 2.15.1

1 0

[alsa-devel] [PATCH] ALSA: aloop: Fix racy hw constraints adjustment
by Takashi Iwai 04 Jan '18

04 Jan '18

The aloop driver tries to update the hw constraints of the connected target on the cable of the opened PCM substream. This is done by adding the extra hw constraints rules referring to the substream runtime->hw fields, while the other substream may update the runtime hw of another side on the fly. This is, however, racy and may result in the inconsistent values when both PCM streams perform the prepare concurrently. One of the reason is that it overwrites the other's runtime->hw field; which is not only racy but also broken when it's called before the open of another side finishes. And, since the reference to runtime->hw isn't protected, the concurrent write may give the partial value update and become inconsistent. This patch is an attempt to fix and clean up: - The prepare doesn't change the runtime->hw of other side any longer, but only update the cable->hw that is referred commonly. - The extra rules refer to the loopback_pcm object instead of the runtime->hw. The actual hw is deduced from cable->hw. - The extra rules take the cable_lock to protect against the race. Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking") Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/drivers/aloop.c | 51 +++++++++++++++++++++------------------------------ 1 file changed, 21 insertions(+), 30 deletions(-) diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c index afac886ffa28..b1eee1a1e925 100644 --- a/sound/drivers/aloop.c +++ b/sound/drivers/aloop.c @@ -305,19 +305,6 @@ static int loopback_trigger(struct snd_pcm_substream *substream, int cmd) return 0; } -static void params_change_substream(struct loopback_pcm *dpcm, - struct snd_pcm_runtime *runtime) -{ - struct snd_pcm_runtime *dst_runtime; - - if (dpcm == NULL || dpcm->substream == NULL) - return; - dst_runtime = dpcm->substream->runtime; - if (dst_runtime == NULL) - return; - dst_runtime->hw = dpcm->cable->hw; -} - static void params_change(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; @@ -329,10 +316,6 @@ static void params_change(struct snd_pcm_substream *substream) cable->hw.rate_max = runtime->rate; cable->hw.channels_min = runtime->channels; cable->hw.channels_max = runtime->channels; - params_change_substream(cable->streams[SNDRV_PCM_STREAM_PLAYBACK], - runtime); - params_change_substream(cable->streams[SNDRV_PCM_STREAM_CAPTURE], - runtime); } static int loopback_prepare(struct snd_pcm_substream *substream) @@ -620,12 +603,14 @@ static unsigned int get_cable_index(struct snd_pcm_substream *substream) static int rule_format(struct snd_pcm_hw_params *params, struct snd_pcm_hw_rule *rule) { - - struct snd_pcm_hardware *hw = rule->private; + struct loopback_pcm *dpcm = rule->private; + struct loopback_cable *cable = dpcm->cable; struct snd_mask *maskp = hw_param_mask(params, rule->var); - maskp->bits[0] &= (u_int32_t)hw->formats; - maskp->bits[1] &= (u_int32_t)(hw->formats >> 32); + mutex_lock(&dpcm->loopback->cable_lock); + maskp->bits[0] &= (u_int32_t)cable->hw.formats; + maskp->bits[1] &= (u_int32_t)(cable->hw.formats >> 32); + mutex_unlock(&dpcm->loopback->cable_lock); memset(maskp->bits + 2, 0, (SNDRV_MASK_MAX-64) / 8); /* clear rest */ if (! maskp->bits[0] && ! maskp->bits[1]) return -EINVAL; @@ -635,11 +620,14 @@ static int rule_format(struct snd_pcm_hw_params *params, static int rule_rate(struct snd_pcm_hw_params *params, struct snd_pcm_hw_rule *rule) { - struct snd_pcm_hardware *hw = rule->private; + struct loopback_pcm *dpcm = rule->private; + struct loopback_cable *cable = dpcm->cable; struct snd_interval t; - t.min = hw->rate_min; - t.max = hw->rate_max; + mutex_lock(&dpcm->loopback->cable_lock); + t.min = cable->hw.rate_min; + t.max = cable->hw.rate_max; + mutex_unlock(&dpcm->loopback->cable_lock); t.openmin = t.openmax = 0; t.integer = 0; return snd_interval_refine(hw_param_interval(params, rule->var), &t); @@ -648,11 +636,14 @@ static int rule_rate(struct snd_pcm_hw_params *params, static int rule_channels(struct snd_pcm_hw_params *params, struct snd_pcm_hw_rule *rule) { - struct snd_pcm_hardware *hw = rule->private; + struct loopback_pcm *dpcm = rule->private; + struct loopback_cable *cable = dpcm->cable; struct snd_interval t; - t.min = hw->channels_min; - t.max = hw->channels_max; + mutex_lock(&dpcm->loopback->cable_lock); + t.min = cable->hw.channels_min; + t.max = cable->hw.channels_max; + mutex_unlock(&dpcm->loopback->cable_lock); t.openmin = t.openmax = 0; t.integer = 0; return snd_interval_refine(hw_param_interval(params, rule->var), &t); @@ -699,19 +690,19 @@ static int loopback_open(struct snd_pcm_substream *substream) /* are cached -> they do not reflect the actual state */ err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT, - rule_format, &runtime->hw, + rule_format, dpcm, SNDRV_PCM_HW_PARAM_FORMAT, -1); if (err < 0) goto unlock; err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, - rule_rate, &runtime->hw, + rule_rate, dpcm, SNDRV_PCM_HW_PARAM_RATE, -1); if (err < 0) goto unlock; err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS, - rule_channels, &runtime->hw, + rule_channels, dpcm, SNDRV_PCM_HW_PARAM_CHANNELS, -1); if (err < 0) goto unlock; -- 2.15.1

1 0

[alsa-devel] [PATCH] ALSA: pcm: Add missing error checks in OSS emulation plugin builder
by Takashi Iwai 04 Jan '18

04 Jan '18

In the OSS emulation plugin builder where the frame size is parsed in the plugin chain, some places miss the possible errors returned from the plugin src_ or dst_frames callback. This patch papers over such places. Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/oss/pcm_plugin.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/sound/core/oss/pcm_plugin.c b/sound/core/oss/pcm_plugin.c index cadc93792868..85a56af104bd 100644 --- a/sound/core/oss/pcm_plugin.c +++ b/sound/core/oss/pcm_plugin.c @@ -592,18 +592,26 @@ snd_pcm_sframes_t snd_pcm_plug_write_transfer(struct snd_pcm_substream *plug, st snd_pcm_sframes_t frames = size; plugin = snd_pcm_plug_first(plug); - while (plugin && frames > 0) { + while (plugin) { + if (frames <= 0) + return frames; if ((next = plugin->next) != NULL) { snd_pcm_sframes_t frames1 = frames; - if (plugin->dst_frames) + if (plugin->dst_frames) { frames1 = plugin->dst_frames(plugin, frames); + if (frames1 <= 0) + return frames1; + } if ((err = next->client_channels(next, frames1, &dst_channels)) < 0) { return err; } if (err != frames1) { frames = err; - if (plugin->src_frames) + if (plugin->src_frames) { frames = plugin->src_frames(plugin, frames1); + if (frames <= 0) + return frames; + } } } else dst_channels = NULL; -- 2.15.1

1 0

Re: [alsa-devel] Headphone issues iMac 14.1 (A1418)
by Takashi Iwai 04 Jan '18

04 Jan '18

On Thu, 04 Jan 2018 17:27:55 +0100, Freaky wrote: > > Hi Takashi, > > we need it to get the headphone output working. Upon unplugging / > replugging we need to check them again (they remain checked, but the output > stops working). The speaker output (onboard speakers) works fine and the > script we run doesn't appear to have any effect on the speaker output at > all. The alsa-info.sh output showed that GPIO[1] is also set, so I wonder how and who sets it. In anyway, could you check whether flipping any such gpio bits turn on / off the headphone and the speaker outputs? Try to toggle it while playing back, such as, hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA xxx where xxx is the value to be written (0x00, 0x02, 0x04, 0x06, etc). > Currently use a python script generated by the HDA Analyzer script that we > run every 5 seconds from boot. Pasted the script below. We run it every 5 > seconds to ensure audio will work after replugging the headphones (although > it might incur a small delay then of course). I don't notice any hick-ups > in audio playback because of the script firing every 5 seconds. > > There's no acpid running from which we could detect the plug event. Using a > system based on Fedora 24. Have watched dbus-monitor (--sytem), but see no > events there upon (un)plugging the headphones which we could use as trigger. The headphone jack detection on HD-audio is usually done via HD-audio codec unsolicited events. You can check "Headphone Jack" ALSA control element (e.g. watch the output of "amixer contents"). Takashi

1 0

[alsa-devel] Headphone issues iMac 14.1 (A1418)
by Freaky 04 Jan '18

04 Jan '18

Hi there, we're having issues enabling the headphone out on an iMac 14.1 (A1418). The parameters snd-hda-intel.model=imac27 or snd-hda-intel.model=imac27_122 do not resolve the problem. Plug detection seems to be working fine, upon plugging the headphone, speaker-out will mute and headphone out will unmute. Unplugging it does the reverse. There's no audio on the headphone out however. We ran the hda analyzer python script and when enabling 'out-dir', 'enable' and 'data' on the GPIO's marked as [2] the audio starts working. If we unplug/plug the headphone then the audio is dead again. Need to uncheck and check them and it will work again. Ran alsa-info.sh, whilst the GPIO's marked as [2] were enabled: http://www.alsa-project.org/db/?f=86db8b16d0118edd1feab9626c68eed4735b943e Would be much obliged if can help with a solution for this. Preferably with a kernel parameter as we run a stateless image that's used on a huge variety of systems. Tried different kernel versions by the way, problem still exists in 4.14.8 at least. Thanks in advance and best wishes for the new year to you all! Kind regards, Ferry

2 1