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

[PATCH v2] ALSA: usb-audio: fix overeager device match for MacroSilicon MS2109
by Hector Martin 10 Aug '20

10 Aug '20

Matching by device matches all interfaces, which breaks the video/HID portions of the device depending on module load order. Cc: stable(a)vger.kernel.org Signed-off-by: Hector Martin <marcan(a)marcan.st> --- sound/usb/quirks-table.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 9092cc0aa807..7cbb3d591a7f 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -3645,7 +3645,13 @@ ALC1220_VB_DESKTOP(0x26ce, 0x0a01), /* Asrock TRX40 Creator */ * with. */ { - USB_DEVICE(0x534d, 0x2109), + .match_flags = USB_DEVICE_ID_MATCH_DEVICE | + USB_DEVICE_ID_MATCH_INT_CLASS | + USB_DEVICE_ID_MATCH_INT_SUBCLASS, + .idVendor = 0x534d, + .idProduct = 0x2109, + .bInterfaceClass = USB_CLASS_AUDIO, + .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { .vendor_name = "MacroSilicon", .product_name = "MS2109", -- 2.27.0

2 1

[PATCH] ALSA: usb-audio: fix overeager device match for MacroSilicon MS2109
by Hector Martin 10 Aug '20

10 Aug '20

Matching by device matches all interfaces, which breaks the video/HID portions of the device depending on module load order. Signed-off-by: Hector Martin <marcan(a)marcan.st> --- sound/usb/quirks-table.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 9092cc0aa807..7cbb3d591a7f 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -3645,7 +3645,13 @@ ALC1220_VB_DESKTOP(0x26ce, 0x0a01), /* Asrock TRX40 Creator */ * with. */ { - USB_DEVICE(0x534d, 0x2109), + .match_flags = USB_DEVICE_ID_MATCH_DEVICE | + USB_DEVICE_ID_MATCH_INT_CLASS | + USB_DEVICE_ID_MATCH_INT_SUBCLASS, + .idVendor = 0x534d, + .idProduct = 0x2109, + .bInterfaceClass = USB_CLASS_AUDIO, + .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { .vendor_name = "MacroSilicon", .product_name = "MS2109", -- 2.27.0

1 0

Low volume with chtmax98090 (Toshiba Chromebook 2/Swanky)
by GitHub issues - edited 10 Aug '20

10 Aug '20

alsa-project/alsa-ucm-conf issue #45 was edited from reanimus: It looks like the UCM configuration for this board is the Chromebook Asus C300 one, but the volume levels set by default are far too low. It looks like when Pulseaudio loads on my system, it follows the initialization steps and results in a really low volume, as the Speaker is set to 27/100 and one must manually set the alsamixer levels to fix it. I could have a periodic task reload the volume state, but I find it better to override the UCM configuration manually and tell my package manager to ignore changes to that file during upgrade. FWIW, my fix is to modify ucm2/codecs/max98090/EnableSeq.conf and change ``` cset "name='Headphone Volume' 10" cset "name='Speaker Volume' 10" ``` to ``` cset "name='Headphone Volume' 80%" cset "name='Speaker Volume' 80%" ``` Naturally, this is a bit of a nasty solution. It'd be nice to have an upstream fix in case other stuff is changed for this. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/45 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Low volume with chtmax98090 (Toshiba Chromebook 2/Swanky)
by GitHub issues - opened 10 Aug '20

10 Aug '20

alsa-project/alsa-ucm-conf issue #45 was opened from reanimus: It looks like the UCM configuration for this board is the Chromebook Asus C300 one, but the volume levels set by default are far too low. It looks like when Pulseaudio loads on my system, it follows the initialization steps and results in a really low volume, as the Speaker is set to 27/100 and one must manually set the alsamixer levels to fix it. I could have a periodic task reload the volume state, but I find it better to override the UCM configuration manually and tell my package manager to ignore changes to that file during upgrade. Naturally, this is a bit of a nasty solution. It'd be nice to have an upstream fix in case other stuff is changed for this. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/45 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

pcm_meter.c issue at s16_update
by Pavel Hofman 09 Aug '20

09 Aug '20

Hi, I am debugging the following problem with the PCM METER API: An application with meter/scope configured in .asoundrc hits a high CPU load sometimes when a new playback stream is opened. E.g. in MPD when opening a new radio stream. The 100% CPU core load takes tens of seconds. Debugging the issue revealed this: TL;DR: at decrease of [status.appl_ptr - status.delay] between consequent runs the size of buffer to convert by the built-in s16 scope is set from usual 100s to huge value of pcm->boundary (1.5G), causing a very long processing at 100% core load. Details: Every scope setup uses a default s16 scope defined in alsa-lib, which converts samples to s16 so that the user-provided scopes can access data via snd_pcm_scope_s16_get_channel_buffer buffers with converted samples. The s16 scope converts samples in a loop, in frames chunks, decrementing size variable by frames until zero. The value of size is hundreds samples max at each s16_update call, calculated in https://github.com/alsa-project/alsa-lib/blob/master/src/pcm/pcm_meter.c#L1… . A debug added after that line shows this: @@ -1098,14 +1103,18 @@ static void s16_update(snd_pcm_scope_t *scope) snd_pcm_sframes_t size; snd_pcm_uframes_t offset; size = meter->now - s16->old; + fprintf(stderr, "s16_update 1: meter->now %ld, s16->old %ld, size %ld\n", meter->now, s16->old, size); if (size < 0) size += spcm->boundary; offset = s16->old % meter->buf_size; s16_update 1: meter->now 2154673, s16->old 2153771, size 902 s16_update 1: meter->now 2155579, s16->old 2154673, size 906 s16_update 1: meter->now 2156487, s16->old 2155579, size 908 s16_update 1: meter->now 2157391, s16->old 2156487, size 904 s16_update 1: meter->now 2158298, s16->old 2157391, size 907 s16_update 1: meter->now 2159203, s16->old 2158298, size 905 s16_update 1: meter->now 2160091, s16->old 2159203, size 888 s16_update 1: meter->now 2160976, s16->old 2160091, size 885 s16_update 1: meter->now 2161924, s16->old 2160976, size 948 s16_update 1: meter->now 2162829, s16->old 2161924, size 905 s16_update 1: meter->now 2163733, s16->old 2162829, size 904 s16_update 1: meter->now 2164594, s16->old 2163733, size 861 s16_update 1: meter->now 2165542, s16->old 2164594, size 948 s16_update 1: meter->now 2166448, s16->old 2165542, size 906 s16_update 1: meter->now 2167352, s16->old 2166448, size 904 s16_update 1: meter->now 2168259, s16->old 2167352, size 907 s16_update 1: meter->now 2169165, s16->old 2168259, size 906 s16_update 1: meter->now 2170050, s16->old 2169165, size 885 s16_update 1: meter->now 2170936, s16->old 2170050, size 886 s16_update 1: meter->now 2171877, s16->old 2170936, size 941 s16_update 1: meter->now 2172783, s16->old 2171877, size 906 s16_update 1: meter->now 2173690, s16->old 2172783, size 907 s16_update 1: meter->now 2174596, s16->old 2173690, size 906 s16_update 1: meter->now 2175502, s16->old 2174596, size 906 s16_update 1: meter->now 2176407, s16->old 2175502, size 905 s16_update 1: meter->now 2177311, s16->old 2176407, size 904 s16_update 1: meter->now 2178215, s16->old 2177311, size 904 However, sometimes meter->now < s16->old, causing size < 0, for which this line applies https://github.com/alsa-project/alsa-lib/blob/master/src/pcm/pcm_meter.c#L1… size += spcm->boundary and size becomes a huge number, because hw:0 pcm -> boundary is 1445068800. The loop at https://github.com/alsa-project/alsa-lib/blob/master/src/pcm/pcm_meter.c#L1… takes tens of seconds, untill the huge buffer is converted to s16. Usually the negative difference is quite small: s16_update 1: meter->now 988, s16->old 21139, size -20151 s16_update 1: meter->now 870, s16->old 18865, size -17995 s16_update 1: meter->now 1065, s16->old 20786, size -19721 s16_update 1: meter->now 701, s16->old 24839, size -24138 s16_update 1: meter->now 782, s16->old 869, size -87 s16_update 1: meter->now 763, s16->old 841, size -78 s16_update 1: meter->now 963, s16->old 22525, size -21562 s16_update 1: meter->now 665, s16->old 832, size -167 s16_update 1: meter->now 745, s16->old 865, size -120 s16_update 1: meter->now 859, s16->old 1002, size -143 s16_update 1: meter->now 935, s16->old 117452, size -116517 Yet in all these cases the size variable is incremented by 1445068800, which clearly does not make sense. Now the question is how it happens that meter->now < s16->old, when meter->now is calculated by now = status.appl_ptr - status.delay https://github.com/alsa-project/alsa-lib/blob/master/src/pcm/pcm_meter.c#L2… and s16->old is set to meter->now at the end of each s16_update call https://github.com/alsa-project/alsa-lib/blob/master/src/pcm/pcm_meter.c#L1… . The debug around the event looks like this, suddenly meter->now drops down: s16_update 1: meter->now 2567498, s16->old 2566593, size 905 s16_update 1: meter->now 2568401, s16->old 2567498, size 903 s16_update 1: meter->now 20786, s16->old 20786, size 0 s16_update 1: meter->now 1065, s16->old 20786, size -19721 s16_update 1: meter->now 24839, s16->old 24838, size 1 s16_update 1: meter->now 701, s16->old 24839, size -24138 s16_update 1: meter->now 1253162, s16->old 701, size 1252461 s16_update 1: meter->now 1255148, s16->old 1253162, size 1986 .......... s16_update 1: meter->now 11136, s16->old 10261, size 875 s16_update 1: meter->now 22525, s16->old 22524, size 1 s16_update 1: meter->now 963, s16->old 22525, size -21562 s16_update 1: meter->now 1270914, s16->old 963, size 1269951 s16_update 1: meter->now 1272917, s16->old 1270914, size 2003 Could it perhaps be an XRUN, causing the difference (status.appl_ptr - status.delay) to actually decrease compared to the previous run? I really do not know how/when such decrease can happen. But if it is a standard situation, than IMO the size of to-be converted buffer by the s16 scope should not be set to the huge pcm->boundary. Thanks a lot for help. Best regards, Pavel.

3 11

Re: [PATCH] ASoC: intel: Fix memory leak in sst_media_open()
by Markus Elfring 09 Aug '20

09 Aug '20

> When power_up_sst() fails, stream needs to be freed > just like when try_module_get() fails. However, current > code is returning directly and ends up leaking memory. Would an imperative wording be preferred for the change description? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… … > +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c > @@ -330,8 +330,10 @@ static int sst_media_open(struct snd_pcm_substream *substream, > runtime->private_data = stream; > > ret_val = power_up_sst(stream); > - if (ret_val < 0) > + if (ret_val < 0) { > + kfree(stream); > return ret_val; > + } … I propose to add a jump target so that a bit of common exception handling code can be better reused at the end of this function implementation. Regards, Markus

1 0

[PATCH v4 00/12] ASoC: qcom: Add support for SC7180 lpass variant
by Rohit kumar 07 Aug '20

07 Aug '20

This patch chain add audio support for SC7180 soc by doing the required modification in existing common lpass-cpu/lpass-platform driver. This also fixes some concurrency issue. Changes since v3: - Fixed yaml documentation comments and make dt_binding_check issues. - Moved general fixes out of sc7180 specific patches as suggested by Srinivas. - Update clock-names to make it same as existing platforms. Ajit Pandey (4): ASoC: qcom: Add common array to initialize soc based core clocks ASoC: qcom: lpass-platform: Replace card->dev with component->dev include: dt-bindings: sound: Add sc7180-lpass bindings header ASoC: qcom: lpass-sc7180: Add platform driver for lpass audio Rohit kumar (8): ASoC: qcom: lpass-cpu: Move ahbix clk to platform specific function ASoC: qcom: lpass-platform: fix memory leak ASoC: qcom: lpass: Use regmap_field for i2sctl and dmactl registers ASoC: qcom: lpass-cpu: fix concurrency issue dt-bindings: sound: lpass-cpu: Add sc7180 lpass cpu node ASoC: qcom: lpass-cpu: Use platform_get_resource ASoC: qcom: lpass-platform: Use platform_get_irq dt-bindings: sound: lpass-cpu: Move to yaml format .../devicetree/bindings/sound/qcom,lpass-cpu.txt | 79 -------- .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 185 ++++++++++++++++++ include/dt-bindings/sound/sc7180-lpass.h | 10 + sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile | 2 + sound/soc/qcom/lpass-apq8016.c | 86 ++++++-- sound/soc/qcom/lpass-cpu.c | 204 ++++++++++--------- sound/soc/qcom/lpass-ipq806x.c | 67 +++++++ sound/soc/qcom/lpass-lpaif-reg.h | 157 ++++++++------- sound/soc/qcom/lpass-platform.c | 155 +++++++++++---- sound/soc/qcom/lpass-sc7180.c | 216 +++++++++++++++++++++ sound/soc/qcom/lpass.h | 63 +++++- 12 files changed, 930 insertions(+), 299 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt create mode 100644 Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml create mode 100644 include/dt-bindings/sound/sc7180-lpass.h create mode 100644 sound/soc/qcom/lpass-sc7180.c -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

4 27

aplay: fix for aborted capture streams
by GitHub pull_request - opened 07 Aug '20

07 Aug '20

alsa-project/alsa-utils pull request #51 was opened from mrajwa: This patch set fixes the issue with capture streams which were aborted by external signal like ctrl+c. Currently functions pcm_read() and pcm_readv() when aborted (in_aborting flag set) return the amount of requested frames instead of those actually read prior to interrupt. The consequence of this is repetition of recent X frames where X stands for amount of frames in one period. This problem is barely visible or rather *audible* when the period is small like few milliseconds because repetition of 1 [ms] of data is not-noticeable however if we use buffer and period sizes in seconds then the problem becomes apparent. Example issue -> https://github.com/thesofproject/sof/issues/3189 Request URL : https://github.com/alsa-project/alsa-utils/pull/51 Patch URL : https://github.com/alsa-project/alsa-utils/pull/51.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[HDAudio][ALC285] Native speaker support for HP Spectre x360 15-eb0xxx
by Alexander Giese 07 Aug '20

07 Aug '20

Hello alsa-devel-team, I have a problem with the built-in speakers on the 2020 model of the hp-spectre. From my unexperienced point of view, the audio sinks are correctly identified and therefore I tried tweaking the GPIO pins with success. Information from alsa-info is here: http://alsa-project.org/db/?f=c8ee13e52fd6b2377573a7123c2887fe4d59c917 When I use hda-verb with the following parameters 2 of 4 of my built-in speakers start working: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02 (or 0x04) hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x01 In addition, my mute-mic-led on the keyboard glows when: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01 (or 0x02) hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x04 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x04 Since I do not understand how the GPIO-settings are integrated and applied in the upstream software for corresponding models, I would very much appreciate any help to get this to work out of the box in future releases so I do not have tweak my system all the time and others can benefit as well. Any suggestions on getting all 4 speakers to work or the mute-volume-led to glow are very much welcome alike! Thank you very much! Alexander

2 2

[PATCH] aplay: capture: write only the amount of read frames
by Rajwa, Marcin 07 Aug '20

07 Aug '20

This patch changes the way aborted stream is being saved. Currently when abort signal happens the write back of read samples is skipped but there is no reason to not save them. Also, we need to know how much frames have been read and write only those. Signed-off-by: Marcin Rajwa <marcin.rajwa(a)linux.intel.com> diff --git a/aplay/aplay.c b/aplay/aplay.c index 6836558..f5010dc 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -3204,11 +3204,12 @@ static void capture(char *orig_name) size_t c = (rest <= (off64_t)chunk_bytes) ? (size_t)rest : chunk_bytes; size_t f = c * 8 / bits_per_frame; - if (pcm_read(audiobuf, f) != f) { + size_t read = pcm_read(audiobuf, f); + size_t save; + if (read != f) in_aborting = 1; - break; - } - if (xwrite(fd, audiobuf, c) != c) { + save = read / 8 * bits_per_frame; + if (xwrite(fd, audiobuf, save) != save) { perror(name); in_aborting = 1; break;

1 0