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

[alsa-devel] [PATCH 0/7] Add devres support to card resources
by Takashi Iwai 04 Oct '18

04 Oct '18

Hi, here is the patchset containing the changes to support a device-managed resource management for ALSA card and memory pages. The actual code changes are identical with the previous RFC series, but a few documentation updates are included in this official set. Takashi === Takashi Iwai (7): ALSA: core: Add device-managed page allocator helper ALSA: core: Add managed card creation ALSA: intel8x0: Allocate resources with device-managed APIs ALSA: atiixp: Allocate resources with device-managed APIs ALSA: hda: Allocate resources with device-managed APIs ALSA: doc: Brush up the old writing-an-alsa-driver ALSA: doc: Add device-managed resource section .../kernel-api/writing-an-alsa-driver.rst | 340 ++++++++++-------- include/sound/core.h | 5 + include/sound/memalloc.h | 4 + sound/core/init.c | 95 ++++- sound/core/memalloc.c | 88 ++++- sound/pci/atiixp.c | 104 ++---- sound/pci/atiixp_modem.c | 104 ++---- sound/pci/hda/hda_controller.h | 1 - sound/pci/hda/hda_intel.c | 43 +-- sound/pci/intel8x0.c | 143 +++----- sound/pci/intel8x0m.c | 143 +++----- 11 files changed, 514 insertions(+), 556 deletions(-) -- 2.18.0

2 19

[alsa-devel] Thread spinning in kernel snd_pcm_link()/snd_pcm_unlink()
by Rob Duncan 02 Oct '18

02 Oct '18

I'm trying to address a bug where we end up with a thread spinning and consuming an entire cpu. The issue seems to be this code in sound/core/pcm_native.c: /* Writer in rwsem may block readers even during its waiting in queue, * and this may lead to a deadlock when the code path takes read sem * twice (e.g. one in snd_pcm_action_nonatomic() and another in * snd_pcm_stream_lock()). As a (suboptimal) workaround, let writer to * spin until it gets the lock. */ static inline void down_write_nonblock(struct rw_semaphore *lock) { while (!down_write_trylock(lock)) cond_resched(); } The original commit for this is 67ec1072b053c15564e6090ab30127895dc77a89 What we're suspecting is that a normal thread (SCHED_OTHER) has a reader lock and a real-time thread using SCHED_RR or SCHED_FIFO is trying to take the writer lock. If both threads are pinned to the same CPU for some reason then the reader thread will never get scheduled (because the real-time writer thread is still runnable), and we will never make progress. Does this sound right? What can we do to fix this? Thanks, Rob.

2 2

[alsa-devel] [PATCH alsa-lib] ioplug: Fix comment in struct snd_pcm_ioplug
by Andre Guedes 02 Oct '18

02 Oct '18

This patch fixes the comment about 'pcm' field in 'struct snd_pcm_ioplug' which wrongly refers to snd_pcm_extplug_create(). Signed-off-by: Andre Guedes <andre.guedes(a)intel.com> --- include/pcm_ioplug.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/pcm_ioplug.h b/include/pcm_ioplug.h index b16fc8b8..81ac8613 100644 --- a/include/pcm_ioplug.h +++ b/include/pcm_ioplug.h @@ -105,7 +105,7 @@ struct snd_pcm_ioplug { */ void *private_data; /** - * PCM handle filled by #snd_pcm_extplug_create() + * PCM handle filled by #snd_pcm_ioplug_create() */ snd_pcm_t *pcm; -- 2.14.4

3 2

[alsa-devel] [PATCH - Multiple plugins 0/4] Fix leaks on multiple plugins
by Andre Guedes 02 Oct '18

02 Oct '18

Hi all, While I was working on AAF plugin RFC v2 series [1], I spotted several leaks in some plugins when handling *_hw_constraint() error cases. This series fixes these issues. Regards, Andre [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2018-September/140290.… Andre Guedes (4): a52: Fix leaks when a52_set_hw_constraint() fails jack: Fix leaks when jack_set_hw_constraint() fails oss: Fix leaks when oss_hw_constraint() fails usb_stream: Fix leaks when us_set_hw_constraint() fails a52/pcm_a52.c | 2 +- jack/pcm_jack.c | 1 + oss/pcm_oss.c | 2 +- usb_stream/pcm_usb_stream.c | 1 + 4 files changed, 4 insertions(+), 2 deletions(-) -- 2.14.4

3 6

[alsa-devel] [PATCH] ALSA: firewire-lib: add PCM rules to obsolete PCM constraints based on LCM of SYT_INTERVAL
by Takashi Sakamoto 02 Oct '18

02 Oct '18

In blocking mode of IEC 61883-1/6, when one isochronous packet includes data for events, the data is for the same number of events as SYT_INTERVAL decided according to sampling transmission frequency (SFC). IEC 61883-1/6 engine of ALSA firewire stack applies constraints of period and buffer size of PCM intermediate buffer of PCM substream. At present, this constraint is designed to round the size up/down to 32 frames. This value comes from the least common multiple (LCM) of SYT_INTERVAL. Although this looks to work well, in lower sampling rate, applications are not allowed to set size of period quite near period time constraint (at present 5 msec per period). This commit adds PCM rules for period/buffer size and rate to obsoletes the constraints based on LCM. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/amdtp-stream.c | 78 +++++++++++++++++++++++++++++++---- 1 file changed, 71 insertions(+), 7 deletions(-) diff --git a/sound/firewire/amdtp-stream.c b/sound/firewire/amdtp-stream.c index cb9acfe60f6a..fcd965f1d69e 100644 --- a/sound/firewire/amdtp-stream.c +++ b/sound/firewire/amdtp-stream.c @@ -140,6 +140,59 @@ const unsigned int amdtp_rate_table[CIP_SFC_COUNT] = { }; EXPORT_SYMBOL(amdtp_rate_table); +static int apply_constraint_to_size(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct snd_interval *s = hw_param_interval(params, rule->var); + const struct snd_interval *r = + hw_param_interval_c(params, SNDRV_PCM_HW_PARAM_RATE); + struct snd_interval t = { + .min = s->min, .max = s->max, .integer = 1, + }; + int i; + + for (i = 0; i < CIP_SFC_COUNT; ++i) { + unsigned int rate = amdtp_rate_table[i]; + unsigned int step = amdtp_syt_intervals[i]; + + if (!snd_interval_test(r, rate)) + continue; + + t.min = roundup(t.min, step); + t.max = rounddown(t.max, step); + } + + if (snd_interval_checkempty(&t)) + return -EINVAL; + + return snd_interval_refine(s, &t); +} + +static int apply_constraint_to_rate(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct snd_interval *r = + hw_param_interval(params, SNDRV_PCM_HW_PARAM_RATE); + const struct snd_interval *s = hw_param_interval_c(params, rule->deps[0]); + struct snd_interval t = { + .min = UINT_MAX, .max = 0, .integer = 1, + }; + int i; + + for (i = 0; i < CIP_SFC_COUNT; ++i) { + unsigned int step = amdtp_syt_intervals[i]; + unsigned int rate = amdtp_rate_table[i]; + + if (s->min % step || s->max % step) + continue; + + t.min = min(t.min, rate); + t.max = max(t.max, rate); + } + + return snd_interval_refine(r, &t); +} + /** * amdtp_stream_add_pcm_hw_constraints - add hw constraints for PCM substream * @s: the AMDTP stream, which must be initialized. @@ -194,16 +247,27 @@ int amdtp_stream_add_pcm_hw_constraints(struct amdtp_stream *s, * number equals to SYT_INTERVAL. So the number is 8, 16 or 32, * depending on its sampling rate. For accurate period interrupt, it's * preferrable to align period/buffer sizes to current SYT_INTERVAL. - * - * TODO: These constraints can be improved with proper rules. - * Currently apply LCM of SYT_INTERVALs. */ - err = snd_pcm_hw_constraint_step(runtime, 0, - SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 32); + err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_SIZE, + apply_constraint_to_size, NULL, + SNDRV_PCM_HW_PARAM_RATE, -1); + if (err < 0) + goto end; + err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, + apply_constraint_to_rate, NULL, + SNDRV_PCM_HW_PARAM_PERIOD_SIZE, -1); + if (err < 0) + goto end; + err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, + apply_constraint_to_size, NULL, + SNDRV_PCM_HW_PARAM_RATE, -1); + if (err < 0) + goto end; + err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, + apply_constraint_to_rate, NULL, + SNDRV_PCM_HW_PARAM_BUFFER_SIZE, -1); if (err < 0) goto end; - err = snd_pcm_hw_constraint_step(runtime, 0, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 32); end: return err; } -- 2.17.1

2 1

[alsa-devel] [PATCH][alsa-lib] timer: fix wrong comment to refer to 'SNDRV_TIMER_PSFLG_*'
by Takashi Sakamoto 02 Oct '18

02 Oct '18

ALSA timer core has a comment referring to 'SNDRV_MIXER_PSFLG_*' in a definition of 'struct snd_timer_params' of UAPI header. I can see this in initial state of ALSA timer core, at least in 'alsa-driver-0.4.0.tar.gz'. This commit fixes the comment. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- include/sound/asound.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/sound/asound.h b/include/sound/asound.h index 6041cab2..4d35c84d 100644 --- a/include/sound/asound.h +++ b/include/sound/asound.h @@ -750,7 +750,7 @@ struct snd_timer_info { #define SNDRV_TIMER_PSFLG_EARLY_EVENT (1<<2) /* write early event to the poll queue */ struct snd_timer_params { - unsigned int flags; /* flags - SNDRV_MIXER_PSFLG_* */ + unsigned int flags; /* flags - SNDRV_TIMER_PSFLG_* */ unsigned int ticks; /* requested resolution in ticks */ unsigned int queue_size; /* total size of queue (32-1024) */ unsigned int reserved0; /* reserved, was: failure locations */ -- 2.17.1

2 1

[alsa-devel] [PATCH] ALSA: timer: fix wrong comment to refer to 'SNDRV_TIMER_PSFLG_*'
by Takashi Sakamoto 02 Oct '18

02 Oct '18

ALSA timer core has a comment referring to 'SNDRV_MIXER_PSFLG_*' in a definition of 'struct snd_timer_params' of UAPI header. I can see this in initial state of ALSA timer core, at least in 'alsa-driver-0.4.0.tar.gz'. This commit fixes the comment. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- include/uapi/sound/asound.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h index ed0a120d4f08..404d4b9ffe76 100644 --- a/include/uapi/sound/asound.h +++ b/include/uapi/sound/asound.h @@ -752,7 +752,7 @@ struct snd_timer_info { #define SNDRV_TIMER_PSFLG_EARLY_EVENT (1<<2) /* write early event to the poll queue */ struct snd_timer_params { - unsigned int flags; /* flags - SNDRV_MIXER_PSFLG_* */ + unsigned int flags; /* flags - SNDRV_TIMER_PSFLG_* */ unsigned int ticks; /* requested resolution in ticks */ unsigned int queue_size; /* total size of queue (32-1024) */ unsigned int reserved0; /* reserved, was: failure locations */ -- 2.17.1

2 1

[alsa-devel] [PATCH] ALSA: hda: Fix mismatch for register mask and value in ext controller.
by Keyon Jie 02 Oct '18

02 Oct '18

E.g. for snd_hdac_ext_bus_link_power_up(), we should set mask to be AZX_MLCTL_SPA(it was 0), and AZX_MLCTL_SPA as value to power up it, here correct it and several similar mismatches. Signed-off-by: Keyon Jie <yang.jie(a)linux.intel.com> --- sound/hda/ext/hdac_ext_controller.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/sound/hda/ext/hdac_ext_controller.c b/sound/hda/ext/hdac_ext_controller.c index 5bc4a1d587d4..60cb00fd0c69 100644 --- a/sound/hda/ext/hdac_ext_controller.c +++ b/sound/hda/ext/hdac_ext_controller.c @@ -48,9 +48,11 @@ void snd_hdac_ext_bus_ppcap_enable(struct hdac_bus *bus, bool enable) } if (enable) - snd_hdac_updatel(bus->ppcap, AZX_REG_PP_PPCTL, 0, AZX_PPCTL_GPROCEN); + snd_hdac_updatel(bus->ppcap, AZX_REG_PP_PPCTL, + AZX_PPCTL_GPROCEN, AZX_PPCTL_GPROCEN); else - snd_hdac_updatel(bus->ppcap, AZX_REG_PP_PPCTL, AZX_PPCTL_GPROCEN, 0); + snd_hdac_updatel(bus->ppcap, AZX_REG_PP_PPCTL, + AZX_PPCTL_GPROCEN, 0); } EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_ppcap_enable); @@ -68,9 +70,11 @@ void snd_hdac_ext_bus_ppcap_int_enable(struct hdac_bus *bus, bool enable) } if (enable) - snd_hdac_updatel(bus->ppcap, AZX_REG_PP_PPCTL, 0, AZX_PPCTL_PIE); + snd_hdac_updatel(bus->ppcap, AZX_REG_PP_PPCTL, + AZX_PPCTL_PIE, AZX_PPCTL_PIE); else - snd_hdac_updatel(bus->ppcap, AZX_REG_PP_PPCTL, AZX_PPCTL_PIE, 0); + snd_hdac_updatel(bus->ppcap, AZX_REG_PP_PPCTL, + AZX_PPCTL_PIE, 0); } EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_ppcap_int_enable); @@ -194,7 +198,8 @@ static int check_hdac_link_power_active(struct hdac_ext_link *link, bool enable) */ int snd_hdac_ext_bus_link_power_up(struct hdac_ext_link *link) { - snd_hdac_updatel(link->ml_addr, AZX_REG_ML_LCTL, 0, AZX_MLCTL_SPA); + snd_hdac_updatel(link->ml_addr, AZX_REG_ML_LCTL, + AZX_MLCTL_SPA, AZX_MLCTL_SPA); return check_hdac_link_power_active(link, true); } @@ -222,8 +227,8 @@ int snd_hdac_ext_bus_link_power_up_all(struct hdac_bus *bus) int ret; list_for_each_entry(hlink, &bus->hlink_list, list) { - snd_hdac_updatel(hlink->ml_addr, - AZX_REG_ML_LCTL, 0, AZX_MLCTL_SPA); + snd_hdac_updatel(hlink->ml_addr, AZX_REG_ML_LCTL, + AZX_MLCTL_SPA, AZX_MLCTL_SPA); ret = check_hdac_link_power_active(hlink, true); if (ret < 0) return ret; @@ -243,7 +248,8 @@ int snd_hdac_ext_bus_link_power_down_all(struct hdac_bus *bus) int ret; list_for_each_entry(hlink, &bus->hlink_list, list) { - snd_hdac_updatel(hlink->ml_addr, AZX_REG_ML_LCTL, AZX_MLCTL_SPA, 0); + snd_hdac_updatel(hlink->ml_addr, AZX_REG_ML_LCTL, + AZX_MLCTL_SPA, 0); ret = check_hdac_link_power_active(hlink, false); if (ret < 0) return ret; -- 2.17.1

2 1

[alsa-devel] Re-reading alsa-lib configuration when opening sound device
by Pavel Hofman 02 Oct '18

02 Oct '18

Hi, I am playing with virtual balanced inputs https://www.diyaudio.com/forums/pc-based/326747-virtual-balanced-regular-so… . For proper functionality it needs a regular recalibration of the ttable multiplication coefficients of route plugin in .asoundrc. The audio stack is alsa -> wine -> Arta measurement software. When I stop measuring in arta (without exiting the software), the soundcard gets closed - confirmed in /proc/asound/.../hw_params. Now I change the ttable coeffs. After re-opening the device (continuing with measurement in the running arta instance) the changes in .asoundrc are ignored. I have to restart the arta application for the changes to take effect. When I run e.g. aplay inbetween, it accepts the changes right away. Upon continuing in arta, the original ttable coeffs are still loaded for this instance. I understand it is the way wine handles the device somewhere in https://github.com/wine-mirror/wine/blob/master/dlls/winealsa.drv/mmdevdrv.c . Please when is the alsa-lib config loaded by the library/application? Is there any way to force a config reload from outside? Would e.g. calling snd_config_update before snd_pcm_open on line https://github.com/wine-mirror/wine/blob/master/dlls/winealsa.drv/mmdevdrv.… help? If so, what overhead does it impose? Perhaps I could ask the wine guys to consider such change if it worked and required minimum overhead. I very much appreciate any help. Best regards, Pavel.

2 4

[alsa-devel] alsactl monitor spins at 100% cpu after unplugging USB headphones
by Thomas Gläßle 02 Oct '18

02 Oct '18

Hi, on both my desktop and laptop (archlinux), `alsactl monitor` beginns spinning at 100% cpu when I unplug my USB headset. This happens every time and can be reproduced as follows: - plug in USB headphones - start `alsactl monitor` - unplug headphones It happens only if the headphones are already plugged in when starting alsactl. The increased activity does not lead to spamming stdout or similar, alsactl continues to perform seemingly correct, i.e. reports when I change volume levels etc, but nothing apart from the ordinary. I'm sorry if this is not the right place to report this issue or if the problem is already, I couldn't find anything about it. Below is the output from alsa-info.sh: with headphones: http://www.alsa-project.org/db/?f=0dfc632e3adafb8bc78a182e0a225bcb13bea9fa after unplugging: http://www.alsa-project.org/db/?f=41dbf0735fdd7cd2416a6b4a602505715d25b44f Please let me know if you need further info. Best regards, Thomas

2 2