June 2022 - Alsa-devel - mailman.alsa-project.org

pcm: Return unsigned int if error occurs by `read` or `write` system call
by GitHub pull_request - opened 19 Jun '22

19 Jun '22

alsa-project/alsa-lib pull request #242 was opened from Korilakkuma: `read` or `write` system call returns `-1` if error occurs. Request URL : https://github.com/alsa-project/alsa-lib/pull/242 Patch URL : https://github.com/alsa-project/alsa-lib/pull/242.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] aplay: Support setting timestamp
by Pavel Hofman 18 Jun '22

18 Jun '22

To allow enabling timestamp and specify its type, a new option --tstamp-type=TYPE is added. Recognized values are none (default), gettimeofday, monotonic, monotonic-raw. Signed-off-by: Pavel Hofman <pavel.hofman(a)ivitera.com> --- aplay/aplay.1 | 4 ++++ aplay/aplay.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) diff --git a/aplay/aplay.1 b/aplay/aplay.1 index 3bba59d..d3b7dce 100644 --- a/aplay/aplay.1 +++ b/aplay/aplay.1 @@ -207,6 +207,10 @@ sampling rates, numbers of channels, period and buffer bytes/sizes/times. For raw device hw:X this option basically lists hardware capabilities of the soundcard. .TP +\fI\-\-tstamp\-type=TYPE\fP +Specifies timestamp type inside the software configuration container. +Types are: none (default), gettimeofday, monotonic, monotonic\-raw. +.TP \fI\-\-fatal\-errors\fP Disables recovery attempts when errors (e.g. xrun) are encountered; the aplay process instead aborts immediately. diff --git a/aplay/aplay.c b/aplay/aplay.c index 63a4e34..5d15a32 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -139,6 +139,8 @@ static int use_strftime = 0; volatile static int recycle_capture_file = 0; static long term_c_lflag = -1; static int dump_hw_params = 0; +static int enable_tstamp = 0; +static snd_pcm_tstamp_type_t tstamp_type = SND_PCM_TSTAMP_TYPE_GETTIMEOFDAY; static int fd = -1; static off64_t pbrec_count = LLONG_MAX, fdcount; @@ -244,6 +246,8 @@ _("Usage: %s [OPTION]... [FILE]...\n" " --process-id-file write the process ID here\n" " --use-strftime apply the strftime facility to the output file name\n" " --dump-hw-params dump hw_params of the device\n" +" --tstamp-type=TYPE set timestamp (TYPE: none (default), gettimeofday,\n" +" monotonic, monotonic-raw)\n" " --fatal-errors treat all errors as fatal\n" ) , command); @@ -430,6 +434,7 @@ enum { OPT_PROCESS_ID_FILE, OPT_USE_STRFTIME, OPT_DUMP_HWPARAMS, + OPT_TSTAMP_TYPE, OPT_FATAL_ERRORS, }; @@ -517,6 +522,7 @@ int main(int argc, char *argv[]) {"use-strftime", 0, 0, OPT_USE_STRFTIME}, {"interactive", 0, 0, 'i'}, {"dump-hw-params", 0, 0, OPT_DUMP_HWPARAMS}, + {"tstamp-type", 1, 0, OPT_TSTAMP_TYPE}, {"fatal-errors", 0, 0, OPT_FATAL_ERRORS}, #ifdef CONFIG_SUPPORT_CHMAP {"chmap", 1, 0, 'm'}, @@ -799,6 +805,23 @@ int main(int argc, char *argv[]) case OPT_DUMP_HWPARAMS: dump_hw_params = 1; break; + case OPT_TSTAMP_TYPE: + if (strcasecmp(optarg, "gettimeofday") == 0) { + enable_tstamp = 1; + tstamp_type = SND_PCM_TSTAMP_TYPE_GETTIMEOFDAY; + } else if (strcasecmp(optarg, "monotonic") == 0) { + enable_tstamp = 1; + tstamp_type = SND_PCM_TSTAMP_TYPE_MONOTONIC; + } else if (strcasecmp(optarg, "monotonic-raw") == 0) { + enable_tstamp = 1; + tstamp_type = SND_PCM_TSTAMP_TYPE_MONOTONIC_RAW; + } else if (strcasecmp(optarg, "none") == 0) + enable_tstamp = 0; + else { + error(_("unrecognized timestamp type %s"), optarg); + return 1; + } + break; case OPT_FATAL_ERRORS: fatal_errors = 1; break; @@ -1453,6 +1476,15 @@ static void set_params(void) stop_threshold = (double) rate * stop_delay / 1000000; err = snd_pcm_sw_params_set_stop_threshold(handle, swparams, stop_threshold); assert(err >= 0); + if (enable_tstamp) { + err = snd_pcm_sw_params_set_tstamp_mode(handle, swparams, SND_PCM_TSTAMP_ENABLE); + assert(err >= 0); + err = snd_pcm_sw_params_set_tstamp_type(handle, swparams, tstamp_type); + if (err < 0) { + error(_("Unable to set the requested timestamp type.")); + prg_exit(EXIT_FAILURE); + } + } if (snd_pcm_sw_params(handle, swparams) < 0) { error(_("unable to install sw params:")); -- 2.25.1

3 6

[PATCH v2 0/3] firewire: fix minor issues
by Takashi Sakamoto 18 Jun '22

18 Jun '22

This second version of patchset is revised version of previous one[1] to fix mistake of macro usage pointed out by reviewer[2]. As I note, they are not so urgent changes, thus I don't mind postponing until next merge window. [1] https://lore.kernel.org/alsa-devel/20220512111756.103008-1-o-takashi@sakamo… [2] https://lore.kernel.org/alsa-devel/87o7yvpf4t.wl-tiwai@suse.de/ Jiapeng Chong (1): firewire: convert sysfs sprintf/snprintf family to sysfs_emit Lv Ruyi (1): firewire: Fix using uninitialized value Minghao Chi (CGEL ZTE) (1): firewire: use struct_size over open coded arithmetic drivers/firewire/core-device.c | 6 ++---- drivers/firewire/core-transaction.c | 3 ++- 2 files changed, 4 insertions(+), 5 deletions(-) -- 2.34.1

2 7

MPG X570S EDGE MAX WIFI compatibility
by GitHub issues - edited 18 Jun '22

18 Jun '22

alsa-project/alsa-ucm-conf issue #172 was edited from yhojann-cl: Please, add `0db0:151f` to `realtek-alc4080` chip compatibility in MPG X570S EDGE MAX WIFI motherboard: ``` $ lsusb | grep 0db0 Bus 001 Device 003: ID 0db0:151f Micro Star International USB Audio ``` In `ucm2/USB-Audio/USB-Audio.conf` add `151f` to regex of `0db0`: ``` Regex "USB((0b05:(1996|1a2[07]))|(0db0:(1feb|419c|a073|151f)))" ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/172 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

MPG X570S EDGE MAX WIFI compatibility
by GitHub issues - opened 18 Jun '22

18 Jun '22

alsa-project/alsa-ucm-conf issue #172 was opened from yhojann-cl: Please, add `0db0:151f` to `realtek-alc4080` chip compatibility in MPG X570S EDGE MAX WIFI motherboard: In `ucm2/USB-Audio/USB-Audio.conf` add `151f` to regex of `0db0`: ``` Regex "USB((0b05:(1996|1a2[07]))|(0db0:(1feb|419c|a073|151f)))" ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/172 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH 0/2] ASoC: SOF/soundwire: use resume_and_get on component probe
by Pierre-Louis Bossart 18 Jun '22

18 Jun '22

While testing driver bind/unbind sequences, I stumbled on a corner case where the SoundWire bus can be suspended before the ASoC card registration happens. During the registration, register accesses would then lead to timeouts. This does not happen in regular usages where the card registration happens within the 3-second time window before suspend. Adding a simple pm_runtime_resume_and_get() on component probe solves the issue, but experiments showed it was too invasive to add at the ASoC core level, with multiple regressions reported by our CI. This patchset limits the additional resume to the SOF and SoundWire codec drivers. An additional patch for the soundwire/intel component will be sent separately. Pierre-Louis Bossart (2): ASoC: SOF: pcm: use pm_resume_and_get() on component probe ASoC: codecs: soundwire: call pm_runtime_resume() in component probe sound/soc/codecs/max98373.c | 14 +++++++++++++- sound/soc/codecs/rt1308-sdw.c | 12 ++++++++++++ sound/soc/codecs/rt1316-sdw.c | 12 ++++++++++++ sound/soc/codecs/rt700.c | 5 +++++ sound/soc/codecs/rt711-sdca.c | 5 +++++ sound/soc/codecs/rt711.c | 5 +++++ sound/soc/codecs/rt715-sdca.c | 12 ++++++++++++ sound/soc/codecs/rt715.c | 12 ++++++++++++ sound/soc/sof/pcm.c | 11 +++++++++++ 9 files changed, 87 insertions(+), 1 deletion(-) -- 2.34.1

2 9

[PATCH v1] ASoC: ops: Fix integer detection for when max possible values > 1
by Stefan Binding 18 Jun '22

18 Jun '22

The standard snd_soc_info_volsw() allows a two value control to be defined as an integer control only if the control name ends in "Volume". It achieves this by creating a substring if it contains " Volume", and ensuring this exists at the end of the name. The volume substring is then used to decide whether the type is a SNDRV_CTL_ELEM_TYPE_INTEGER or SNDRV_CTL_ELEM_TYPE_BOOLEAN. However this volume substring is only computed for a two value control. This means for controls where there are more than two possible values, the substring is never created, so in this case the substring remains NULL, and the condition yields SNDRV_CTL_ELEM_TYPE_BOOLEAN, even though there are more than 2 possible values. If there are more than 2 possible values for the control, then it should always be an integer control. Fixes: aa2a4b897132 ("ASoC: ops: Fix boolean/integer detection for simple controls") Signed-off-by: Stefan Binding <sbinding(a)opensource.cirrus.com> --- sound/soc/soc-ops.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c index 0267e39de2a8..1970bda074d8 100644 --- a/sound/soc/soc-ops.c +++ b/sound/soc/soc-ops.c @@ -183,17 +183,16 @@ int snd_soc_info_volsw(struct snd_kcontrol *kcontrol, if (mc->platform_max && mc->platform_max < max) max = mc->platform_max; - /* Even two value controls ending in Volume should always be integer */ if (max == 1) { + /* Even two value controls ending in Volume should always be integer */ vol_string = strstr(kcontrol->id.name, " Volume"); - if (vol_string && strcmp(vol_string, " Volume")) - vol_string = NULL; - } - - if (!vol_string) - uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; - else + if (vol_string && !strcmp(vol_string, " Volume")) + uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; + else + uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; + } else { uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; + } uinfo->count = snd_soc_volsw_is_stereo(mc) ? 2 : 1; uinfo->value.integer.min = 0; -- 2.25.1

3 2

[PATCH v2] ASoC: mediatek: mt8186: Fix mutex double unlock in GPIO request
by Fei Shao 18 Jun '22

18 Jun '22

The lockdep mechanism revealed an unbalanced unlocking on MT8186: [ 2.993966] WARNING: bad unlock balance detected! [ 2.993978] ------------------------------------- [ 2.993983] kworker/u16:1/10 is trying to release lock (gpio_request_mutex) at: [ 2.993994] [<ffffffdcd9adebf8>] mt8186_afe_gpio_request+0xf8/0x210 [ 2.994012] but there are no more locks to release! The cause is that the mutex will be double unlocked if dai is unknown during GPIO selection, and this patch fixes it. Fixes: cfa9a966f12a ("ASoC: mediatek: mt8186: support gpio control in platform driver") Signed-off-by: Fei Shao <fshao(a)chromium.org> --- Changes in v2: - Trimmed the commit message sound/soc/mediatek/mt8186/mt8186-afe-gpio.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c index 255ffba637d3..274c0c8ec2f2 100644 --- a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c +++ b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c @@ -230,7 +230,6 @@ int mt8186_afe_gpio_request(struct device *dev, bool enable, sel = enable ? MT8186_AFE_GPIO_PCM_ON : MT8186_AFE_GPIO_PCM_OFF; break; default: - mutex_unlock(&gpio_request_mutex); dev_err(dev, "%s(), invalid dai %d\n", __func__, dai); goto unlock; } -- 2.36.1.476.g0c4daa206d-goog

2 1

[PATCH] ASoC: mediatek: mt8186: Fix mutex double unlock in GPIO request
by Fei Shao 18 Jun '22

18 Jun '22

The lockdep mechanism reveals an unbalanced unlocking on MT8186: [ 2.993966] WARNING: bad unlock balance detected! [ 2.993971] 5.15.46-421fef3b44d7-lockdep #16 Not tainted [ 2.993978] ------------------------------------- [ 2.993983] kworker/u16:1/10 is trying to release lock (gpio_request_mutex) at: [ 2.993994] [<ffffffdcd9adebf8>] mt8186_afe_gpio_request+0xf8/0x210 [ 2.994012] but there are no more locks to release! [ 2.994017] [ 2.994017] other info that might help us debug this: [ 2.994022] 3 locks held by kworker/u16:1/10: [ 2.994028] #0: ffffff80c004a148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1a8/0x364 [ 2.994054] #1: ffffffc0080d3d58 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1d0/0x364 [ 2.994074] #2: ffffff80c12ab9a0 (&dev->mutex){....}-{3:3}, at: __device_attach+0x44/0x150 [ 2.994096] [ 2.994096] stack backtrace: [ 2.994102] CPU: 6 PID: 10 Comm: kworker/u16:1 Not tainted 5.15.46-421fef3b44d7-lockdep #16 a2af0e2c6b3eeab6799b5aa8091c1d05d3a7bbb1 [ 2.994113] Hardware name: Google Kingler board (DT) [ 2.994120] Workqueue: events_unbound deferred_probe_work_func [ 2.994130] Call trace: [ 2.994135] dump_backtrace+0x0/0x1d4 [ 2.994144] show_stack+0x20/0x2c [ 2.994152] dump_stack_lvl+0x78/0x9c [ 2.994163] dump_stack+0x18/0x44 [ 2.994172] print_unlock_imbalance_bug+0xf0/0xf4 [ 2.994184] lock_release+0x150/0x388 [ 2.994193] __mutex_unlock_slowpath+0x4c/0x1bc [ 2.994202] mutex_unlock+0x44/0x50 [ 2.994210] mt8186_afe_gpio_request+0xf8/0x210 [ 2.994220] mt8186_afe_gpio_init+0xcc/0x134 [ 2.994230] mt8186_mt6366_rt1019_rt5682s_dev_probe+0x14c/0x220 [ 2.994238] platform_probe+0xb0/0xd0 [ 2.994247] really_probe+0xcc/0x2c8 [ 2.994253] __driver_probe_device+0xbc/0xe8 [ 2.994264] driver_probe_device+0x48/0xf0 [ 2.994271] __device_attach_driver+0xa0/0xc8 [ 2.994278] bus_for_each_drv+0x8c/0xd8 [ 2.994288] __device_attach+0xc4/0x150 [ 2.994298] device_initial_probe+0x1c/0x28 [ 2.994308] bus_probe_device+0x3c/0xa0 [ 2.994318] deferred_probe_work_func+0xa0/0xe0 [ 2.994325] process_one_work+0x208/0x364 [ 2.994334] worker_thread+0x288/0x3fc [ 2.994343] kthread+0x140/0x160 [ 2.994351] ret_from_fork+0x10/0x20 The cause is that the mutex will be double unlocked if dai is unknown during GPIO selection, and this patch fixes it. Fixes: cfa9a966f12a ("ASoC: mediatek: mt8186: support gpio control in platform driver") Signed-off-by: Fei Shao <fshao(a)chromium.org> --- sound/soc/mediatek/mt8186/mt8186-afe-gpio.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c index 255ffba637d3..274c0c8ec2f2 100644 --- a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c +++ b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c @@ -230,7 +230,6 @@ int mt8186_afe_gpio_request(struct device *dev, bool enable, sel = enable ? MT8186_AFE_GPIO_PCM_ON : MT8186_AFE_GPIO_PCM_OFF; break; default: - mutex_unlock(&gpio_request_mutex); dev_err(dev, "%s(), invalid dai %d\n", __func__, dai); goto unlock; } -- 2.36.1.476.g0c4daa206d-goog

2 3

[PATCH 0/3] ASoC: SOF: Intel: fix resume from hibernate
by Pierre-Louis Bossart 18 Jun '22

18 Jun '22

The enablement of IMR-based DSP boot helped reduce resume latency, but unfortunately the context is not saved in S4 and S5 which leads to multiple reports of boot failures. This patchset forces a full firmware reload/reboot when resuming from S4/S5 and restores functionality. Pierre-Louis Bossart (3): ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2 ASoC: SOF: pm: add definitions for S4 and S5 states ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states sound/soc/sof/intel/hda-loader.c | 3 ++- sound/soc/sof/pm.c | 21 ++++++++++++++++++++- sound/soc/sof/sof-priv.h | 2 ++ 3 files changed, 24 insertions(+), 2 deletions(-) -- 2.34.1

2 4