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

[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

Re: [alsa-devel] [PATCH 1/6] ASoC: rt5645: change micbias widget type to supply.
by Mark Brown 04 Jan '18

04 Jan '18

On Thu, Jan 04, 2018 at 12:20:06PM +0000, Bard Liao wrote: > > > Yes, it's supply usage for a micbias. So it didn't take effect with > > > MICBIAS widget type. Actually, we don't need to set the micbias > > > power bit for headset mic and we have verified it today. So, I will > > > send a patch to remove them soon. > > Are you sure that's likely to be helpful? > Yes, I checked the register dump and the micbias power bits are > not set. The register settings will be the same if we remove it, > and it is verified. On the other hand, the micbias power bits will > be set and the micbias_event will be invoked after we convert the > micbias widget type to SUPPLY if we don't remove it. But are you sure that this was working properly for the Mediatek systems previously and your and Hans' patches don't actually fix a bug for them too? If that's the case then removing the supply hookup would cause a bug for them.

1 0