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

Re: [alsa-devel] [PATCH 1/3] ARM: configs: omap2plus: Add tlv320aic23 as module
by Tony Lindgren 25 Sep '18

25 Sep '18

* Adam Ford <aford173(a)gmail.com> [180923 08:41]: > The AM3517 EVM has an expander board which has two tlv320aic23 > codecs. This enables the driver for these codecs as a module. Applying into omap-for-v4.20/defconfig thanks. Tony

1 0

Re: [alsa-devel] [PATCH 3/3] ARM: OMAP2PLUS: Remove references to AM3517-EVM since it's in DT
by Tony Lindgren 25 Sep '18

25 Sep '18

* Adam Ford <aford173(a)gmail.com> [180923 08:41]: > Since the audio codecs used on the AM3517-EVM are now available > in device tree, and the audio driver wasn't really being used > anyway, this patch removes the remaining AM3517 legacy board > options and sound soc drivers. Mark do you want to pick this one? If so: Acked-by: Tony Lindgren <tony(a)atomide.com> Maybe update the subject line according too. Regards, Tony

1 0

Re: [alsa-devel] [PATCH 2/3] ARM: DTS: AM3517-EVM: Add support for UI board and Audio
by Tony Lindgren 25 Sep '18

25 Sep '18

* Adam Ford <aford173(a)gmail.com> [180923 15:41]: > The full AM3517-EVM shipped with an add-on board which contained > two Audio codecs, a GPIO expander with a variety of buttons, and > some other features. This patch enables these portions of the UI > board because they don't directly conflict with existing features. Applying this one into omap-for-v4.20/dt thanks. Tony

1 0

[alsa-devel] [PATCH] ASoC: cs4265: Add a MIC pre. route
by Matt Flax 24 Sep '18

24 Sep '18

The cs4265 driver is missing a microphone preamp enable. This patch enables/disables the microphone preamp when mic selection is made using the kcontrol. Signed-off-by: Matt Flax <flatmax(a)flatmax.org> --- sound/soc/codecs/cs4265.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/soc/codecs/cs4265.c b/sound/soc/codecs/cs4265.c index 275677de..332d714a 100644 --- a/sound/soc/codecs/cs4265.c +++ b/sound/soc/codecs/cs4265.c @@ -230,6 +230,10 @@ static const struct snd_soc_dapm_route cs4265_audio_map[] = { {"DAI1 Capture", NULL, "DOUT"}, {"DAI2 Capture", NULL, "DOUT"}, + { "Pre-amp MIC", NULL, "MICL" }, + { "Pre-amp MIC", NULL, "MICR" }, + { "ADC Mux", "MIC", "Pre-amp MIC" }, + /* Loopback */ {"Loopback", "Switch", "ADC"}, {"DAC", NULL, "Loopback"}, -- 2.17.1

2 1

Re: [alsa-devel] [PATCH 3/3] ARM: OMAP2PLUS: Remove references to AM3517-EVM since it's in DT
by Jarkko Nikula 23 Sep '18

23 Sep '18

On 09/23/18 18:37, Adam Ford wrote: > Since the audio codecs used on the AM3517-EVM are now available > in device tree, and the audio driver wasn't really being used > anyway, this patch removes the remaining AM3517 legacy board > options and sound soc drivers. > > Signed-off-by: Adam Ford <aford173(a)gmail.com> > For sound/soc/omap/ changes: Acked-by: Jarkko Nikula <jarkko.nikula(a)bitmer.com>

1 0

[alsa-devel] Pinpoint audio audio corruption (Layla3G)
by Mark Hills 23 Sep '18

23 Sep '18

I have a bug in ALSA somewhere; playback is corrupted. Nothing is pro-actively telling me of a problem (eg. underrun) I could use some assistance getting to the bottom of this. Listen to [1] for what it sounds like -- analogue recording from the output. Look at the waveform [2] in Baudlien and it seems both L+R channels geting zero'd for some buffer period of 2.5 or 5 milliseconds. This is Layla3G, snd-echo3g. This problem has been rare, but persisted for many years. I've finally got something reproducable to investigate. It began ~10 years ago where very occasionally recordings or playback would do this. This was a simple self-contained application in production use; written by me, using plughw:Layla3G,0,0 (no desktops, browsers, dmix etc.) Problems were frequent enough to be annoying, but infrequent enough that I just had to put it down to 'cosmic rays', with no useful bug report. These days I am on a desktop using dmix; and more recently with Google Chrome and found I can reliably 'trigger' it. To reset, I must close all applications using /dev/snd, and re-open. It seems to be: * whether or not Google Chrome is first to open the device * about 10-60 minutes after Chrome has opened the device * more prone to happening if other applications are using the dmix * not related to buffer sizes; I use larger sizes in the asoundrc it doesn't affect the likelihood, or the 'sound' when it does happen * I've seen two Layla's affected * I've had many kernels and PCs over the years There's a bug somewhere, and with nothing printed to dmesg, console etc., I'm at a loss here, imagining my problem could be anywhere between dmix, alsa-lib, snd-echo3g or even the firmware itself. Whatever the case, I've finally got some combination I can do in userland as a trigger. Below is: - .asoundrc describing today's setup (previously I used stereo with no route, still with problems) - output of the 'aplay' that produced the recording above; and - some other stats. [1] http://www.pogo.org.uk/~mark/tmp/layla-glitch.flac [2] http://www.pogo.org.uk/~mark/tmp/layla-glitch.png Many thanks -- Mark pcm.!default { type plug slave.pcm layla_multi } pcm.layla_multi { type route slave.pcm { type dmix ipc_key 1742 slave { pcm "hw:Layla3G,0,0" period_size 992 buffer_size 10912 channels 5 rate 48000 format S16_LE } } ttable { # Headphones 0.0 1 1.1 1 # Speakers 0.2 1 1.3 1 # Subwoofer; mono mix 0.4 0.5 1.4 0.5 } } $ uname -a Linux stax 4.18.5 #113 SMP PREEMPT Mon Sep 3 23:14:59 BST 2018 x86_64 Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz GenuineIntel GNU/Linux $ head -99l /proc/asound/Layla3G/pcm0p/sub0/* ==> /proc/asound/Layla3G/pcm0p/sub0/hw_params <== access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 6 rate: 48000 (48000/1) period_size: 992 buffer_size: 10912 ==> /proc/asound/Layla3G/pcm0p/sub0/info <== card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: Analog PCM name: Layla3G subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 8 subdevices_avail: 7 ==> /proc/asound/Layla3G/pcm0p/sub0/prealloc <== 128 ==> /proc/asound/Layla3G/pcm0p/sub0/prealloc_max <== 256 ==> /proc/asound/Layla3G/pcm0p/sub0/status <== state: RUNNING owner_pid : 9250 trigger_time: 663739.627559736 tstamp : 680208.555428028 delay : -790500256 avail : 790511168 avail_max : 790511168 ----- hw_ptr : 790500256 appl_ptr : 0 ==> /proc/asound/Layla3G/pcm0p/sub0/sw_params <== tstamp_mode: ENABLE period_step: 1 avail_min: 1 start_threshold: 1 stop_threshold: 6142909891733356544 silence_threshold: 0 silence_size: 6142909891733356544 boundary: 6142909891733356544 $ aplay -vv all48000.wav Playing WAVE 'all48000.wav' : Float 32 bit Little Endian, Rate 48000 Hz, Stereo Plug PCM: Linear Integer <-> Linear Float conversion PCM (S16_LE) Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : FLOAT_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 32 buffer_size : 10912 period_size : 992 period_time : 20666 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 992 period_event : 0 start_threshold : 10912 stop_threshold : 10912 silence_threshold: 0 silence_size : 0 boundary : 6142909891733356544 Slave: Route conversion PCM (sformat=S16_LE) Transformation table: 0 <- 0 1 <- 1 2 <- none 3 <- none 4 <- none 5 <- none Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 10912 period_size : 992 period_time : 20666 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 992 period_event : 0 start_threshold : 10912 stop_threshold : 10912 silence_threshold: 0 silence_size : 0 boundary : 6142909891733356544 Slave: Route conversion PCM Transformation table: 0 <- 0 1 <- 1 2 <- 0 3 <- 1 4 <- 0*0.5 + 1*0.5 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 6 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 10912 period_size : 992 period_time : 20666 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 992 period_event : 0 start_threshold : 10912 stop_threshold : 10912 silence_threshold: 0 silence_size : 0 boundary : 6142909891733356544 Slave: Direct Stream Mixing PCM Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 6 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 10912 period_size : 992 period_time : 20666 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 992 period_event : 0 start_threshold : 10912 stop_threshold : 10912 silence_threshold: 0 silence_size : 0 boundary : 6142909891733356544 Hardware PCM card 0 'Layla3G' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 6 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 10912 period_size : 992 period_time : 20666 tstamp_mode : ENABLE tstamp_type : MONOTONIC period_step : 1 avail_min : 992 period_event : 0 start_threshold : 1 stop_threshold : 0 silence_threshold: 0 silence_size : 0 boundary : 6142909891733356544 appl_ptr : 0 hw_ptr : 807111136 ############################ + | 56%^C Aborted by signal Interrupt... aplay: pcm_write:2004: write error: Interrupted system call

1 0

[alsa-devel] [PATCH] ALSA: usb-audio: ensure that cluster header size is enough
by Dan Carpenter 22 Sep '18

22 Sep '18

I think we need a check to make sure that "hc_header.wLength" is large enough for a struct struct uac3_cluster_header_descriptor. Fixes: 9a2fe9b801f5 ("ALSA: usb: initial USB Audio Device Class 3.0 support") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/usb/stream.c b/sound/usb/stream.c index 67cf849aa16b..f7179ce39a19 100644 --- a/sound/usb/stream.c +++ b/sound/usb/stream.c @@ -968,6 +968,12 @@ snd_usb_get_audioformat_uac3(struct snd_usb_audio *chip, * and request Cluster Descriptor */ wLength = le16_to_cpu(hc_header.wLength); + if (wLength < sizeof(*cluster)) { + dev_err(&dev->dev, + "%u:%d : cluster header size too small %d\n", + iface_no, altno, wLength); + return ERR_PTR(-EIO); + } cluster = kzalloc(wLength, GFP_KERNEL); if (!cluster) return ERR_PTR(-ENOMEM);

2 1

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Add custom mixer status quirks for RME CC devices
by Jussi Laako 22 Sep '18

22 Sep '18

Hi Takashi, Please hold applying the patch, I'm having final checks with RME regarding the VID or VID:PID based approach when to use this functionality. If it seems better to use strict VID:PID table instead, I will send an updated patch. - Jussi

1 0

[alsa-devel] [RFC] ALSA: usb-audio: Add custom mixer status quirks for RME CC devices
by Jussi Laako 22 Sep '18

22 Sep '18

This patch accessing vendor specific registers of RME Class Compliant devices works otherwise fine, but there is still one small problem. It is supposed to be a polled from the hardware, since the values indicate device status and are subject to change at all times. Behavior is correct if I keep running "amixer" all the time to retrieve values - sampling rate changes are visible and values get updated. However, when I poll the values from an application without reopening the mixer, they are being cached somewhere and the changes are not reflected. This problem doesn't exist for example with PCIe based RME HDSPe AIO and application gets updated values, but in this USB based device case they don't get updated. I have flagged all the mixer controls as read-only and volatile, but the volatile flag is not honored in this (assuming I've understood it correctly). Any guidance on how to fix the caching problem is welcome!

3 10

[alsa-devel] [PATCH 0/2] ASoC: for_each_component_xx() macro
by Kuninori Morimoto 21 Sep '18

21 Sep '18

Hi Mark These are v2 of for_each_component_xx() macro. v1 -> v2 is renamed comment_all to comment. Kuninori Morimoto (2): ASoC: add for_each_component() macro ASoC: add for_each_component_dais() macro include/sound/soc.h | 5 +++++ sound/soc/soc-core.c | 35 ++++++++++++++++++++--------------- 2 files changed, 25 insertions(+), 15 deletions(-) -- 2.7.4

2 4