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

aplay: playing mono audio file alteres pulseaudio default Master left or right volume level
by GitHub issues - edited 16 Sep '20

16 Sep '20

alsa-project/alsa-utils issue #55 was edited from maxmbed: ### Description I am encountering an unexpected behaviour with pulse audio master volume in my application. If I set for example left channel to 100% and right channel 0%, and play mono audio file (i.e. audio file with 1 channel only), then I would expect to hear only the audio file on left channel. The actual behaviour in the example of above is when playing the audio file, the Master volume right channel will be automatically adjusted to 50%. If play again it increases to 75% and so on. This issue happens also with other R/L volume level, the case of above is just an example. **Important to note the case does not happen with stereo audio file** where audio sounds on left only channel as we can expect. ### Steps to repeat issue: (a) Set mixer Lch to 100%, Rch to 0% ``` $ amixer -D default sset Master 65535,0 Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 65535 [100%] [on] Front Right: Playback 0 [0%] [on] ``` (b) Play mono audio file ``` $ aplay -D default ringtone.wav Playing WAVE 'ringtone.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono ``` ### Request (1) Is it by design expected ? (2) Is there a way to prevent this phenomenon (command option) ? Issue URL : https://github.com/alsa-project/alsa-utils/issues/55 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

aplay: playing mono audio file alteres pulseaudio default Master left or right volume level
by GitHub issues - edited 16 Sep '20

16 Sep '20

alsa-project/alsa-utils issue #55 was edited from maxmbed: ### Description I am encountering an unexpected behaviour with pulse audio master volume in my application. If I set for example left channel to 100% and right channel 0%, and play mono audio file (i.e. audio file with 1 channel only), then I would expect to hear only the audio file on left channel. The actual behaviour in the example of above is when playing the audio file, the Master volume right channel will be automatically adjusted to 50%. If play again it increases to 75% and so on. This issue happens also with other R/L volume level, the case of above is just an example. **Important to note the case does not happen with stereo audio file** where audio sounds on left only channel as we can expected. ### Steps to repeat issue: (a) Set mixer Lch to 100%, Rch to 0% ``` $ amixer -D default sset Master 65535,0 Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 65535 [100%] [on] Front Right: Playback 0 [0%] [on] ``` (b) Play mono audio file ``` $ aplay -D default ringtone.wav Playing WAVE 'ringtone.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono ``` ### Request (1) Is it by design expected ? (2) Is there a way to prevent this phenomenon (command option) ? Issue URL : https://github.com/alsa-project/alsa-utils/issues/55 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

aplay: playing mono audio file alteres pulseaudio default Master left or right volume level
by GitHub issues - opened 16 Sep '20

16 Sep '20

alsa-project/alsa-utils issue #55 was opened from maxmbed: ### Description I am encountering an expected behaviour with pulse audio master volume in my application. If I set for example left channel to 100% and right channel 0%, and play mono audio file (i.e. audio file with 1 channel only), then I would expect to hear only the audio file on left channel. The actual behaviour in the example of above is when playing the audio file, the Master volume right channel will be automatically adjusted to 50%. If play again it increases to 75% and so on. This issue happens also with other R/L volume level, the case of above is just an example. **Important to note the case does not happen with stereo audio file** where audio sounds on left only channel as we can expected. ### Steps to repeat issue: (a) Set mixer Lch to 100%, Rch to 0% ``` $ amixer -D default sset Master 65535,0 Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 65535 [100%] [on] Front Right: Playback 0 [0%] [on] ``` (b) Play mono audio file ``` $ aplay -D default ringtone.wav Playing WAVE 'ringtone.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono ``` ### Request (1) Is it by design expected ? (2) Is there a way to prevent this phenomenon (command option) ? Issue URL : https://github.com/alsa-project/alsa-utils/issues/55 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Re: [PATCH] fsl: imx-audmix: Use devm_kcalloc() in imx_audmix_probe()
by Markus Elfring 16 Sep '20

16 Sep '20

> A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the corresponding function "devm_kcalloc". I find the previous patch subject inappropriate. Would you like to choose an alternative? Regards, Markus

1 0

Re: [PATCH v2 3/3] ASoC: tlv320adcx140: Add proper support for master mode
by Dan Murphy 16 Sep '20

16 Sep '20

Camel On 9/16/20 2:52 AM, Camel Guo wrote: > Please forget about this patch since Dan will upload a similar one. > > @Dan, see my comment below. > I have cc'd you on my patchset and as you can see I did not add any of the master mode programming only setting of the master mode bits. So this patch is still viable it's just the master mode bit programming that needs to be looked at. Dan

1 0

[PATCH v3 00/11] USB: new USB control message helper functions
by Greg Kroah-Hartman 16 Sep '20

16 Sep '20

In a recent discussion about a USB networking bug found by syzbot, and fixed by Himadri Pandya, the design of the existing usb_control_msg() call was brought up as not being the "nicest" thing to use by Dmitry Vyukov: https://lore.kernel.org/r/CACT4Y+YbDODLRFn8M5QcY4CazhpeCaunJnP_udXtAs0rYoAS… The function makes it hard to get right, in that it will return the number of bytes sent/received, but almost no one checks to see if a short read/write happens. With a malicious, or broken, USB device, this can cause drivers to act on data that they did not anticipate, and sometimes copy internal kernel data out to userspace. So let's fix this up by creating two new functions, usb_control_msg_send() and usb_control_msg_recv(). These functions either complete the full transation, or they return an error, a short send/recv is now an error. They also accept data off of the stack, saving individual drivers the pain of having to constantly allocate memory on their own for tiny messages, thereby saving overall kernel code space. The api also does not require a raw USB "pipe" to be sent to the function, as we know the direction, so just pass in the endpoint number instead, again making it easier on the USB driver author to use. This series first takes a helper function out of the sound core for verifying USB endpoints to be able to use internally, and then adds the new functions, converts over some internal USB code to use them, and then starts to clean up some drivers using these new functions, as an example of the savings that can happen by using these functions. Thanks to Dmitry and Himadri for the idea on how to do all of this. greg k-h ----- Changes from v2: - add Andy's reviewed-by: to patch 3 - remove unneeded change in usb_enable_link_state() in hub.c in patch 4 Changes from v1: - added acks from Takashi Iwai - dropped changes to one function in patch 04 thanks to review from Alan Stern - typo fix in comment in patch 01 - added new patch 11 to remove some unneeded checks in the sound drivers for endpoint statuses that would always be true. Greg Kroah-Hartman (11): USB: move snd_usb_pipe_sanity_check into the USB core USB: add usb_control_msg_send() and usb_control_msg_recv() USB: core: message.c: use usb_control_msg_send() in a few places USB: core: hub.c: use usb_control_msg_send() in a few places USB: legousbtower: use usb_control_msg_recv() sound: usx2y: move to use usb_control_msg_send() sound: 6fire: move to use usb_control_msg_send() and usb_control_msg_recv() sound: line6: move to use usb_control_msg_send() and usb_control_msg_recv() sound: hiface: move to use usb_control_msg_send() Bluetooth: ath3k: use usb_control_msg_send() and usb_control_msg_recv() ALSA: remove calls to usb_pipe_type_check for control endpoints drivers/bluetooth/ath3k.c | 90 +++++------------ drivers/usb/core/hub.c | 99 ++++++++---------- drivers/usb/core/message.c | 171 ++++++++++++++++++++++++++++---- drivers/usb/core/urb.c | 31 ++++-- drivers/usb/misc/legousbtower.c | 60 ++++------- include/linux/usb.h | 7 ++ sound/usb/6fire/firmware.c | 38 +++---- sound/usb/helper.c | 16 +-- sound/usb/helper.h | 1 - sound/usb/hiface/pcm.c | 14 ++- sound/usb/line6/driver.c | 69 +++++-------- sound/usb/line6/podhd.c | 17 ++-- sound/usb/line6/toneport.c | 8 +- sound/usb/mixer_scarlett_gen2.c | 2 +- sound/usb/quirks.c | 12 +-- sound/usb/usx2y/us122l.c | 42 ++------ 16 files changed, 336 insertions(+), 341 deletions(-) -- 2.28.0

2 13

[PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties
by Krzysztof Kozlowski 16 Sep '20

16 Sep '20

Additional properties actually might appear (e.g. assigned-clocks) so use unevaluatedProperties to fix dtbs_check warnings like: arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: system-controller@105c0000: 'assigned-clock-parents', 'assigned-clocks' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> --- Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml index 686c13c14e32..30ff2da81416 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml @@ -86,7 +86,7 @@ required: - compatible - reg -additionalProperties: false +unevaluatedProperties: false allOf: - if: -- 2.17.1

6 35

[PATCH v2 1/3] dt-bindings: tlv320adcx140: Add GPIO config and drive config
by Camel Guo 15 Sep '20

15 Sep '20

From: Camel Guo <camelg(a)axis.com> Add properties for configuring the General Purpose Input Outputs (GPIO). There are 2 settings for GPIO, configuration and the output drive type. Signed-off-by: Camel Guo <camelg(a)axis.com> --- .../bindings/sound/tlv320adcx140.yaml | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index f578f17f3e04..7b0b4554da59 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -134,6 +134,49 @@ patternProperties: 4d - Drive weak low and active high 5d - Drive Hi-Z and active high + ti,gpio-config: + description: | + Defines the configuration and output driver for the general purpose + input and output pin (GPIO1). Its value is a pair, the first value is for + the configuration type and the second value is for the output drive + type. The array is defined as <GPIO1_CFG GPIO1_DRV> + + configuration for the GPIO pin can be one of the following: + 0 - disabled + 1 - GPIO1 is configured as a general-purpose output (GPO) + 2 - (default) GPIO1 is configured as a device interrupt output (IRQ) + 3 - GPIO1 is configured as a secondary ASI output (SDOUT2) + 4 - GPIO1 is configured as a PDM clock output (PDMCLK) + 8 - GPIO1 is configured as an input to control when MICBIAS turns on or + off (MICBIAS_EN) + 9 - GPIO1 is configured as a general-purpose input (GPI) + 10 - GPIO1 is configured as a master clock input (MCLK) + 11 - GPIO1 is configured as an ASI input for daisy-chain (SDIN) + 12 - GPIO1 is configured as a PDM data input for channel 1 and channel 2 + (PDMDIN1) + 13 - GPIO1 is configured as a PDM data input for channel 3 and channel 4 + (PDMDIN2) + 14 - GPIO1 is configured as a PDM data input for channel 5 and channel 6 + (PDMDIN3) + 15 - GPIO1 is configured as a PDM data input for channel 7 and channel 8 + (PDMDIN4) + + output drive type for the GPIO pin can be one of the following: + 0 - Hi-Z output + 1 - Drive active low and active high + 2 - (default) Drive active low and weak high + 3 - Drive active low and Hi-Z + 4 - Drive weak low and active high + 5 - Drive Hi-Z and active high + + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32-array + - minItems: 2 + maxItems: 2 + items: + maximum: 15 + default: [2, 2] + required: - compatible - reg @@ -150,6 +193,7 @@ examples: ti,mic-bias-source = <6>; ti,pdm-edge-select = <0 1 0 1>; ti,gpi-config = <4 5 6 7>; + ti,gpio-config = <10 2>; ti,gpo-config-1 = <0 0>; ti,gpo-config-2 = <0 0>; reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; -- 2.20.1

2 6

Re: [PATCH v4 2/5] ASoC: dt-bindings: Add dt binding for lpass hdmi
by Rob Herring 15 Sep '20

15 Sep '20

On Tue, Sep 08, 2020 at 05:44:39PM +0000, Srinivasa Rao Mandadapu wrote: > From: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> > > Adds bindings for lpass hdmi interface > which can support audio path over dp. > > Signed-off-by: Srinivasa Rao <srivasam(a)codeaurora.org> > Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> > --- > .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 51 ++++++++++++++++++++-- > 1 file changed, 47 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml > index 09c9bd2..7c2ac0c 100644 > --- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml > +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml > @@ -22,6 +22,7 @@ properties: > - qcom,lpass-cpu > - qcom,apq8016-lpass-cpu > - qcom,sc7180-lpass-cpu > + - qcom,sc7180-lpass-hdmi > > reg: > maxItems: 1 > @@ -60,10 +61,12 @@ properties: > const: 0 > > patternProperties: > - "(^mi2s-[0-9a-f]$|mi2s)": > + "^dai@[0-9a-f]$": > type: object > - description: Required properties for each DAI > - > + description: | > + LPASS CPU dai node for each I2S device. Bindings of each node > + depends on the specific driver providing the functionality and > + properties. > properties: > reg: > maxItems: 1 > @@ -145,6 +148,22 @@ allOf: > - iommus > - power-domains > > + - if: > + properties: > + compatible: > + contains: > + const: qcom,sc7180-lpass-hdmi > + then: > + properties: > + clock-names: > + items: > + - const: pcnoc-sway-clk > + - const: audio-core > + - const: pcnoc-mport-clk > + required: > + - iommus > + - power-domains > + > examples: > - | > #include <dt-bindings/sound/sc7180-lpass.h> > @@ -178,12 +197,36 @@ examples: > #address-cells = <1>; > #size-cells = <0>; > /* Optional to set different MI2S SD lines */ > - mi2s-primary@0 { > + dai@mi2s-primary { The unit address should be a number. As this is not failing checks, then you are missing an 'additionalProperties: false'. > reg = <MI2S_PRIMARY>; > qcom,playback-sd-lines = <1>; > qcom,capture-sd-lines = <0>; > }; > }; > + > + lpassh@62d87000 { > + compatible = "qcom,sc7180-lpass-hdmi"; > + > + reg = <0 0x62d87000 0 0x68000>; > + > + iommus = <&apps_smmu 0x1032 0>; > + > + power-domains = <&lpass_hm 0>; > + > + clocks = <&gcc 131>, > + <&lpasscc 6>, > + <&lpasscc 10>; > + > + clock-names = "pcnoc-sway-clk", "audio-core", > + "pcnoc-mport-clk"; > + > + #sound-dai-cells = <1>; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + interrupts = <0 268 1>; > + }; > }; > > ... > -- > Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., > is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. >

1 0

[RFC] dpcm_fe_dai_do_trigger: implicit removal of _DRAIN cmd since v5.4
by Cezary Rojewski 15 Sep '20

15 Sep '20

Hello, Till v5.4 dpcm_fe_dai_do_trigger was supporting all pcm cmds as each case: SND_SOC_DPCM_TRIGGER_PRE/ _POST/ _BESPOKE was simply passing cmd's value to appropriate variant of _trigger(). Since the addition of: acbf27746ecfa96b290b54cc7f05273482ea128a ASoC: pcm: update FE/BE trigger order based on the command additional filters have been introduced for _PRE and _POST cases: switch (cmd) { case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: ret = dpcm_dai_trigger_fe_be(substream, cmd, true); break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: ret = dpcm_dai_trigger_fe_be(substream, cmd, false); break; default: ret = -EINVAL; break; } effectively removing support for _DRAIN command - all requests will yield -EINVAL. _BESPOKE was left alone so support remained there. Now, is DPCM no longer supporting _DRAIN and that's how things should be -or- DPCM still intends to support _DRAIN and mentioned change is unintended regression? Czarek

2 1