October 2021 - Alsa-devel - mailman.alsa-project.org

[PATCH MANUALSEL 4.14] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index 8f0f05bbc081..23a15d892e50 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -145,7 +145,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

[PATCH MANUALSEL 4.19 2/2] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index 8f0f05bbc081..23a15d892e50 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -145,7 +145,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

[PATCH MANUALSEL 5.4 4/4] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index 8f0f05bbc081..23a15d892e50 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -145,7 +145,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

[PATCH MANUALSEL 5.10 7/7] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index ed40d0f7432c..773db4bf0876 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -143,7 +143,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

Re: [PATCH 2/2] ASoC: rt9120: Add rt9210 audio amplifier support
by ChiYuan Huang 06 Oct '21

06 Oct '21

Hi, Mark: Mark Brown <broonie(a)kernel.org> 於 2021年10月5日週二下午8:44寫道： > > On Tue, Oct 05, 2021 at 08:36:44PM +0800, ChiYuan Huang wrote: > > Mark Brown <broonie(a)kernel.org> 於 2021年10月5日週二下午7:54寫道： > > > On Tue, Oct 05, 2021 at 09:16:55AM +0800, cy_huang wrote: > > > > > + /* Default config volume to 0dB */ > > > > + snd_soc_component_write(comp, RT9120_REG_MSVOL, 0x180); > > > > + /* Mute by default */ > > > > + snd_soc_component_update_bits(comp, RT9120_REG_VOLRAMP, > > > > + RT9120_MUTE_MASK, RT9120_MUTE_MASK); > > > > As ever you should leave the defaults at whatever the hardware defaults > > > to, the defaults for one machine may not be suitable for another so we > > > shouldn't be trying to do that in software. > > > The default volume will be kept in value 0x7ff (mute). > > I just want to follow the ASoC flow to control mute/unmute mask by AMP on/off. > > If to default set volume to 0dB and mute is improper, user have to use > > mixer control to configure the volume. > > Does mute function also need to be removed also? > > It's totally fine and indeed quite common for devices to be muted by > default - usually systems will have UCM profiles that unmute things by > the time users actually interact with them. > > Please don't take things off-list unless there is a really strong reason > to do so. Sending things to the list ensures that everyone gets a > chance to read and comment on things. After asking the HW member, there's already builtin HW volume ramp function. Mute API is still no need. There's already no pop issue without mute function. So the next change, I'll remove the default volume and mute config, and also mute API. Thx.

1 0

[RFC PATCH v1 0/1] ASoC: meson: aiu: HDMI codec control questions and issues
by Martin Blumenstingl 05 Oct '21

05 Oct '21

Hello Jerome et al., on Amlogic Meson SoCs which use the AIU audio controller we have the so-called "machine gun noise" (MGN) issue, reproducible for example in Kodi. So far nobody was able to identify the cause of this issue. My idea was to at least narrow down the issue so we can categorize it. For that I wanted to get the SPDIF output from AIU to the HDMI controller working. On Amlogic Meson GXBB/GXL/GXM SoCs a DesignWare HDMI TX controller is used. This has an SPDIF input but there's currently not driver for it. On Meson8/8b/8m2 SoCs I am working on a HDMI driver for the TransSwitch HDMI controller which - just like DesignWare HDMI TX - supports SPDIF and I2S inputs. I decided to add SPDIF support to the latter since the code from the vendor driver is much easier. It took me a while to figure out why I would not get any audio output from AIU SPDIF to the HDMI controller - or from there to the sink. The "fix" for this issue is the RFC patch which is part of this series. Any feedback would be great as I am still new to the ASoC subsystem. Another part I am still struggling with is the audio "routing" (due to lack of a better term - please correct me if this is not the right word to use for this case). I have the following description in my .dts: sound { compatible = "amlogic,gx-sound-card"; model = "M8B-ODROID-C1"; assigned-clocks = <&clkc CLKID_MPLL0>, <&clkc CLKID_MPLL1>; assigned-clock-rates = <294912000>, <270950400>; dai-link-0 { sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; }; dai-link-1 { sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>; }; dai-link-2 { sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; dai-format = "i2s"; mclk-fs = <256>; codec-0 { sound-dai = <&aiu AIU_HDMI CTRL_I2S>; }; }; dai-link-3 { sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>; codec-0 { sound-dai = <&aiu AIU_HDMI CTRL_PCM>; }; }; dai-link-4 { sound-dai = <&aiu AIU_HDMI CTRL_OUT>; codec-0 { sound-dai = <&hdmi_tx>; }; }; }; The driver for &hdmi_tx defines: struct hdmi_codec_pdata pdata = { .ops = &txc_48352_hdmi_codec_ops, .i2s = 1, .spdif = 1, .max_i2s_channels = 8, .data = priv, }; In hdmi_codec_ops.hw_params I always get fmt->fmt HDMI_I2S unless I remove all I2S references from the .dts snipped above (only then HDMI_SPDIF is detected). Based on the selection of the "HDMI Source" enum in aiu-codec-ctrl I was expecting the format to update as well. That unfortunately doesn't happen and I don't know how that can be achieved. Best regards, Martin Martin Blumenstingl (1): ASoC: meson: aiu: Fix HDMI codec control selection sound/soc/meson/aiu-codec-ctrl.c | 108 ++++++++++++++++++++++-------- sound/soc/meson/aiu-encoder-i2s.c | 6 -- 2 files changed, 80 insertions(+), 34 deletions(-) -- 2.33.0

5 13

[PATCH] alsaloop: fixed parsing value 'auto' of option 'sync'
by Pavel Hofman 05 Oct '21

05 Oct '21

The value 'auto' was not checked for which resulted in using SYNC_TYPE_NONE instead of SYNC_TYPE_AUTO. Signed-off-by: Pavel Hofman <pavel.hofman(a)ivitera.com> --- alsaloop/alsaloop.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/alsaloop/alsaloop.c b/alsaloop/alsaloop.c index 4192712..f5f2e37 100644 --- a/alsaloop/alsaloop.c +++ b/alsaloop/alsaloop.c @@ -528,6 +528,8 @@ static int parse_config(int argc, char *argv[], snd_output_t *output, arg_sync = SYNC_TYPE_PLAYRATESHIFT; else if (optarg[0] == 'r') arg_sync = SYNC_TYPE_SAMPLERATE; + else if (optarg[0] == 'a') + arg_sync = SYNC_TYPE_AUTO; else arg_sync = atoi(optarg); if (arg_sync < 0 || arg_sync > SYNC_TYPE_LAST) -- 2.25.1

1 0

[PATCH] alsaloop: added option prateshift for ctl elem used in PLAYSHIFT sync
by Pavel Hofman 05 Oct '21

05 Oct '21

If snd-aloop device is on playback side, the required sync mode is PLAYSHIFT. That means Loopback ctl elem "PCM Rate Shift 100000" of the corresponding capture side of the Loopback pipe must be controlled (by a reciprocal). ASCII name of the playback rate shift ctl elem is specified with newly added option -x/--prateshift, e.g.: -P hw:Loopback,0 -S playshift \ -x iface=PCM,name='PCM Rate Shift 100000',device=1 Signed-off-by: Pavel Hofman <pavel.hofman(a)ivitera.com> --- alsaloop/alsaloop.1 | 11 ++++-- alsaloop/alsaloop.c | 11 +++++- alsaloop/alsaloop.h | 1 + alsaloop/pcmjob.c | 86 ++++++++++++++++++++++++++++++++++----------- 4 files changed, 86 insertions(+), 23 deletions(-) diff --git a/alsaloop/alsaloop.1 b/alsaloop/alsaloop.1 index 6bacfd5..006494d 100644 --- a/alsaloop/alsaloop.1 +++ b/alsaloop/alsaloop.1 @@ -57,6 +57,11 @@ Use given CTL device for playback. Use given CTL device for capture. +.TP +\fI\-x <ctl_ascii_name>\fP | \fI\-\-prateshift=<ctl_ascii_name>\fP + +Specify ctl ascii name for playshift sync mode (see the Examples section). + .TP \fI\-l <latency>\fP | \fI\-\-latency=<frames>\fP @@ -195,10 +200,12 @@ Verbose xrun profiling. Set process wake timeout. .SH EXAMPLES - -.TP +.nf \fBalsaloop \-C hw:0,0 \-P hw:1,0 \-t 50000\fR +\fBalsaloop \-C hw:soundcard,0 \-P hw:Loopback,0 \-t 50000 \-S playshift \\ +\-x iface=PCM,name='PCM Rate Shift 100000',device=1\fR +.ne .SH BUGS None known. .SH AUTHOR diff --git a/alsaloop/alsaloop.c b/alsaloop/alsaloop.c index 06ffadf..4192712 100644 --- a/alsaloop/alsaloop.c +++ b/alsaloop/alsaloop.c @@ -175,6 +175,7 @@ void help(void) "-C,--cdevice capture device\n" "-X,--pctl playback ctl device\n" "-Y,--cctl capture ctl device\n" +"-x,--prateshift playback 'PCM Rate Shift 100000' ascii ctl name\n" "-l,--latency requested latency in frames\n" "-t,--tlatency requested latency in usec (1/1000000sec)\n" "-f,--format sample format\n" @@ -362,6 +363,7 @@ static int parse_config(int argc, char *argv[], snd_output_t *output, {"cdevice", 1, NULL, 'C'}, {"pctl", 1, NULL, 'X'}, {"cctl", 1, NULL, 'Y'}, + {"prateshift", 1, NULL, 'x'}, {"latency", 1, NULL, 'l'}, {"tlatency", 1, NULL, 't'}, {"format", 1, NULL, 'f'}, @@ -391,6 +393,7 @@ static int parse_config(int argc, char *argv[], snd_output_t *output, char *arg_cdevice = NULL; char *arg_pctl = NULL; char *arg_cctl = NULL; + char *arg_prateshift = NULL; unsigned int arg_latency_req = 0; unsigned int arg_latency_reqtime = 10000; snd_pcm_format_t arg_format = SND_PCM_FORMAT_S16_LE; @@ -420,7 +423,7 @@ static int parse_config(int argc, char *argv[], snd_output_t *output, while (1) { int c; if ((c = getopt_long(argc, argv, - "hdg:P:C:X:Y:l:t:F:f:c:r:s:benvA:S:a:m:T:O:w:UW:z", + "hdg:P:C:X:Y:x:l:t:F:f:c:r:s:benvA:S:a:m:T:O:w:UW:z", long_option, NULL)) < 0) break; switch (c) { @@ -446,6 +449,9 @@ static int parse_config(int argc, char *argv[], snd_output_t *output, case 'Y': arg_cctl = strdup(optarg); break; + case 'x': + arg_prateshift = strdup(optarg); + break; case 'l': err = atoi(optarg); arg_latency_req = err >= 4 ? err : 4; @@ -627,6 +633,9 @@ static int parse_config(int argc, char *argv[], snd_output_t *output, logit(LOG_CRIT, "Unable to add ossmixer controls.\n"); exit(EXIT_FAILURE); } + if (arg_prateshift) + play->prateshift_name = arg_prateshift; + #ifdef USE_SAMPLERATE loop->src_enable = arg_samplerate > 0; if (loop->src_enable) diff --git a/alsaloop/alsaloop.h b/alsaloop/alsaloop.h index 1dbcefe..7a98ef3 100644 --- a/alsaloop/alsaloop.h +++ b/alsaloop/alsaloop.h @@ -127,6 +127,7 @@ struct loopback_handle { snd_ctl_elem_value_t *ctl_format; snd_ctl_elem_value_t *ctl_rate; snd_ctl_elem_value_t *ctl_channels; + char *prateshift_name; /* ascii name for the playback rate shift ctl elem */ }; struct loopback { diff --git a/alsaloop/pcmjob.c b/alsaloop/pcmjob.c index 845ab82..4b56d03 100644 --- a/alsaloop/pcmjob.c +++ b/alsaloop/pcmjob.c @@ -1101,7 +1101,8 @@ void update_pitch(struct loopback *loop) #endif } else if (loop->sync == SYNC_TYPE_PLAYRATESHIFT) { - set_rate_shift(loop->play, pitch); + // pitch is capture-based, playback side requires reciprocal + set_rate_shift(loop->play, 1 / pitch); #ifdef USE_SAMPLERATE if (loop->use_samplerate) { loop->src_data.src_ratio = @@ -1172,44 +1173,89 @@ static int get_channels(struct loopback_handle *lhandle) return snd_ctl_elem_value_get_integer(lhandle->ctl_channels, 0); } -static void openctl_elem(struct loopback_handle *lhandle, - int device, int subdevice, - const char *name, - snd_ctl_elem_value_t **elem) +static int openctl_elem_id(struct loopback_handle *lhandle, snd_ctl_elem_id_t *id, + snd_ctl_elem_value_t **elem) { int err; if (snd_ctl_elem_value_malloc(elem) < 0) { *elem = NULL; + return -ENOMEM; + } + snd_ctl_elem_value_set_id(*elem, id); + snd_ctl_elem_value_set_interface(*elem, SND_CTL_ELEM_IFACE_PCM); + err = snd_ctl_elem_read(lhandle->ctl, *elem); + if (err < 0) { + snd_ctl_elem_id_free(id); + snd_ctl_elem_value_free(*elem); + *elem = NULL; + return err; } else { - snd_ctl_elem_value_set_interface(*elem, - SND_CTL_ELEM_IFACE_PCM); - snd_ctl_elem_value_set_device(*elem, device); - snd_ctl_elem_value_set_subdevice(*elem, subdevice); - snd_ctl_elem_value_set_name(*elem, name); - err = snd_ctl_elem_read(lhandle->ctl, *elem); - if (err < 0) { - snd_ctl_elem_value_free(*elem); - *elem = NULL; - } else { - if (verbose) - snd_output_printf(lhandle->loopback->output, - "Opened PCM element %s of %s, device %d, subdevice %d\n", - name, snd_ctl_name(lhandle->ctl), device, subdevice); - } + snd_output_printf(lhandle->loopback->output, + "Opened PCM element %s of %s, device %d, subdevice %d\n", + snd_ctl_elem_id_get_name(id), snd_ctl_name(lhandle->ctl), + snd_ctl_elem_id_get_device(id), + snd_ctl_elem_id_get_subdevice(id)); + return 0; } } +static int openctl_elem(struct loopback_handle *lhandle, + int device, int subdevice, + const char *name, + snd_ctl_elem_value_t **elem) +{ + snd_ctl_elem_id_t *id; + + if (snd_ctl_elem_id_malloc(&id)) + return -ENOMEM; + snd_ctl_elem_id_set_device(id, device); + snd_ctl_elem_id_set_subdevice(id, subdevice); + snd_ctl_elem_id_set_name(id, name); + return openctl_elem_id(lhandle, id, elem); +} + +static int openctl_elem_ascii(struct loopback_handle *lhandle, char *ascii_name, + snd_ctl_elem_value_t **elem) +{ + snd_ctl_elem_id_t *id; + + if (snd_ctl_elem_value_malloc(elem) < 0) + return -ENOMEM; + if (snd_ctl_elem_id_malloc(&id)) { + snd_ctl_elem_value_free(*elem); + return -ENOMEM; + } + if (snd_ctl_ascii_elem_id_parse(id, ascii_name)) { + snd_ctl_elem_id_free(id); + snd_ctl_elem_value_free(*elem); + fprintf(stderr, "Wrong control identifier: %s\n", ascii_name); + return -EINVAL; + } + return openctl_elem_id(lhandle, id, elem); +} + static int openctl(struct loopback_handle *lhandle, int device, int subdevice) { int err; lhandle->ctl_rate_shift = NULL; if (lhandle->loopback->play == lhandle) { + // play only + if (lhandle->prateshift_name) { + err = openctl_elem_ascii(lhandle, lhandle->prateshift_name, + &lhandle->ctl_rate_shift); + if (err < 0) { + logit(LOG_CRIT, "Unable to open playback PCM Rate Shift elem '%s'.\n", + lhandle->prateshift_name); + exit(EXIT_FAILURE); + } + } if (lhandle->loopback->controls) goto __events; return 0; } + // capture only openctl_elem(lhandle, device, subdevice, "PCM Notify", &lhandle->ctl_notify); openctl_elem(lhandle, device, subdevice, "PCM Rate Shift 100000", -- 2.25.1

1 0

[PATCH v3 00/16] ASoC: Add Rich Graph Card support
by Kuninori Morimoto 05 Oct '21

05 Oct '21

Hi Mark We already have Audio-Graph-Card which is Of-Graph base general sound card driver. Basically it supports basic CPU-Codec connection, and is also supporting DPCM connection. Because it was forcibly expanded to DPCM, DT parsing is very limited and very difficult to add new features on it, for example Multi-CPU/Codec support, Codec2Codec support, etc. This patch adds more flexible new Rich-Graph-Card driver for it. Audio-Graph-Card and Rich-Graph-Card are similar, but don't have full compatibility. The reason why I need Rich-Graph-Card instead of updating Audio-Graph-Card is that it is very difficult to keep compatibility. Rich-Graph-Card supports Normal/DPCM/Codec2Codec Connection wich Single/Multi DAIs. And it is possible to Customizing. This patch-set adds Rich-Graph-Card driver and customized driver sample, and DT settings sample which can be used for testing. To enable testing/debuging, this patch-set also adds Test-Component driver. We already have Dummy Component and/or Dummy DAI on soc-utils, but 1) we can't use it from DT, 2) it do nothing. Added new Test-Component can be used from DT, and it can indicate called function name. We can use it to trace callback order, understanding ALSA SoC behavior, etc, etc... Sample DT settings of Rich Graph Card is using Test-Component as CPU/Codec DAI. You can easily try to use/test it if you added below line to your DT file. Your .config needs to have below CONFIGs to use/test it. It will probe sample Sound Card which has Normal/DPCM/Multi/Codec2Codec connections. #include "../../../../../sound/soc/generic/rich-graph-card-sample.dtsi" CONFIG_SND_RICH_GRAPH_CARD CONFIG_SND_RICH_CUSTOM_CARD_SAMPLE CONFIG_SND_TEST_COMPONENT Because Audio Graph Card2 is still under experimental stage, it will indicate such warning when probing, and the DT might be updated/exchanged. It can use Codec2Codec, but it will start automatically when probed, and can't stop it so far. It should be updated. Link: https://lore.kernel.org/r/87k0xszlep.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/871r8u4s6q.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87a6mhwyqn.wl-kuninori.morimoto.gx@renesas.com v1 -> v2 - don't use "port" base for_each loop v2 -> v3 - Rename audio-graph-card2 to rich-graph-card - Rename DSP to DPCM not to confuse - Normal/DPCM/Codec2Codec can use Single/Multi DAIs. - use dpcm/multi/codec2codec node instead of using extra compatible - Sample DTSI patch is separated to Single/Multi. Kuninori Morimoto (16): ASoC: test-component: add Test Component YAML bindings ASoC: test-component: add Test Component for Sound debug/test ASoC: simple-card-utils: add asoc_graph_is_ports0() ASoC: simple-card-utils: add codec2codec support ASoC: add Rich Graph Card driver ASoC: rich-graph-card: add Multi CPU/Codec support ASoC: rich-graph-card: add DPCM support ASoC: rich-graph-card: add Codec2Codec support ASoC: add Rich Graph Card Yaml Document ASoC: add Rich Graph Card Custom Sample ASoC: rich-graph-card-sample.dtsi: add Sample DT for Normal (Single) ASoC: rich-graph-card-sample.dtsi: add Sample DT for Normal (Nulti) ASoC: rich-graph-card-sample.dtsi: add DPCM sample (Single) ASoC: rich-graph-card-sample.dtsi: add DPCM sample (Multi) ASoC: rich-graph-card-sample.dtsi: add Codec2Codec sample (Single) ASoC: rich-graph-card-sample.dtsi: add Codec2Codec sample (Multi) .../bindings/sound/rich-graph-card.yaml | 57 + .../bindings/sound/test-component.yaml | 33 + include/sound/graph_card.h | 21 + include/sound/simple_card_utils.h | 4 + sound/soc/generic/Kconfig | 20 + sound/soc/generic/Makefile | 6 + sound/soc/generic/rich-custom-card-sample.c | 174 +++ sound/soc/generic/rich-graph-card-sample.dtsi | 225 +++ sound/soc/generic/rich-graph-card.c | 1277 +++++++++++++++++ sound/soc/generic/simple-card-utils.c | 46 +- sound/soc/generic/test-component.c | 659 +++++++++ 11 files changed, 2521 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/sound/rich-graph-card.yaml create mode 100644 Documentation/devicetree/bindings/sound/test-component.yaml create mode 100644 sound/soc/generic/rich-custom-card-sample.c create mode 100644 sound/soc/generic/rich-graph-card-sample.dtsi create mode 100644 sound/soc/generic/rich-graph-card.c create mode 100644 sound/soc/generic/test-component.c -- 2.25.1

3 28

[PATCH 0/3] ASoC: SOF: topology: minor updates
by Pierre-Louis Bossart 05 Oct '21

05 Oct '21

Two patches to visualize settings and override dynamic pipelines + one correction for errors on connections. Pierre-Louis Bossart (2): ASoC: SOF: topology: show clks_control value in dynamic debug ASoC: SOF: topology: allow for dynamic pipelines override for debug Ranjani Sridharan (1): ASoC: SOF: topology: return error if sof_connect_dai_widget() fails sound/soc/sof/sof-priv.h | 6 ++++++ sound/soc/sof/topology.c | 24 +++++++++++++++--------- 2 files changed, 21 insertions(+), 9 deletions(-) -- 2.25.1

2 4