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

[PATCH v2] ALSA: hda: generic: Remove redundant assignment to dac
by Jiapeng Chong 14 May '21

14 May '21

Variable dac is set to zero, but this value is never read as it is overwritten or not used later on, hence it is a redundant assignment and can be removed. Clean up the following clang-analyzer warning: sound/pci/hda/hda_generic.c:1436:4: warning: Value stored to 'dac' is never read [clang-analyzer-deadcode.DeadStores]. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- Changes in v2: -For the follow advice: https://lore.kernel.org/patchwork/patch/1423536/ sound/pci/hda/hda_generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index b638fc2..fc02957 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1433,7 +1433,7 @@ static int try_assign_dacs(struct hda_codec *codec, int num_outs, path = snd_hda_add_new_path(codec, dac, pin, 0); } if (!path) { - dac = dacs[i] = 0; + dacs[i] = 0; badness += bad->no_dac; } else { /* print_nid_path(codec, "output", path); */ -- 1.8.3.1

2 1

[PATCH] ASoC: SOF: Intel: hda: don't send DAI_CONFIG IPC for older firmware
by Ranjani Sridharan 13 May '21

13 May '21

BE hw_params op was recently added for SSP type DAIs. But sending the DAI_CONFIG IPC during hw_params is not supported with older firmware. So add an ABI check to avoid sending the IPC if the firmware ABI is older than 3.18. Fixes: e12be9fbfb91 ('ASoC: SOF: Intel: HDA: add hw params callback for SSP DAIs') Tested-by: Yong Zhi <yong.zhi(a)intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> --- sound/soc/sof/intel/hda-dai.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/soc/sof/intel/hda-dai.c b/sound/soc/sof/intel/hda-dai.c index 8d7bab433fb3..c1f9f0f58464 100644 --- a/sound/soc/sof/intel/hda-dai.c +++ b/sound/soc/sof/intel/hda-dai.c @@ -421,11 +421,16 @@ static int ssp_dai_hw_params(struct snd_pcm_substream *substream, struct snd_soc_pcm_runtime *rtd = asoc_substream_to_rtd(substream); struct snd_soc_component *component = snd_soc_rtdcom_lookup(rtd, SOF_AUDIO_PCM_DRV_NAME); struct snd_sof_dev *sdev = snd_soc_component_get_drvdata(component); + struct sof_ipc_fw_version *v = &sdev->fw_ready.version; struct sof_ipc_dai_config *config; struct snd_sof_dai *sof_dai; struct sof_ipc_reply reply; int ret; + /* DAI_CONFIG IPC during hw_params is not supported in older firmware */ + if (v->abi_version < SOF_ABI_VER(3, 18, 0)) + return 0; + list_for_each_entry(sof_dai, &sdev->dai_list, list) { if (!sof_dai->cpu_dai_name || !sof_dai->dai_config) continue; -- 2.25.1

1 0

X-Fi USB HD - switching from USB1.1 to USB2?
by Pavel Hofman 13 May '21

13 May '21

Hi, The X-Fi USB HD device (and likely the similar 5.1 model too) can run at USB1.1 (with limited samplerates) and USB2 modes (with full specs). In linux the device stays at USB1.1. If connected to Windows with stock windows USB driver the same happens. However, when the Creative proprietary driver is installed, the device switches to USB2 and supports all features. When rebooting to linux without re-plugging, the USB2 mode stays and the device offers its USB2 configurations to snd-usb-audio. We captured USB packets in linux and Win7 with wireshark - both dumps are included. The windows dump shows that in windows as well as in linux the device starts as device 3.5.0 at USB1.1: DEVICE DESCRIPTOR bLength: 18 bDescriptorType: 0x01 (DEVICE) bcdUSB: 0x0110 bDeviceClass: Device (0x00) bDeviceSubClass: 0 bDeviceProtocol: 0 (Use class code info from Interface Descriptors) bMaxPacketSize0: 64 idVendor: Creative Technology, Ltd (0x041e) idProduct: Unknown (0x30d7) bcdDevice: 0x0100 iManufacturer: 1 iProduct: 2 iSerialNumber: 3 bNumConfigurations: 1 After USB1.1 enumeration, the windows host controlled by the vendor driver sends a request USR_FUNCTION_ABORT_PIPE to EP IN 6: The EP IN 6 descriptor (from USB1.1 configuration): ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: 0x05 (ENDPOINT) bEndpointAddress: 0x86 IN Endpoint:6 1... .... = Direction: IN Endpoint .... 0110 = Endpoint Number: 0x6 bmAttributes: 0x03 .... ..11 = Transfertype: Interrupt-Transfer (0x3) wMaxPacketSize: 64 ...0 0... .... .... = Transactions per microframe: 1 (0) .... ..00 0100 0000 = Maximum Packet Size: 64 bInterval: 1 The request sent by the host is: USB URB [Source: host] [Destination: 3.5.6] USBPcap pseudoheader length: 27 IRP ID: 0xfffffa80073ee120 IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) URB Function: URB_FUNCTION_ABORT_PIPE (0x0002) IRP information: 0x00, Direction: FDO -> PDO URB bus id: 3 Device address: 5 Endpoint: 0x86, Direction: IN URB transfer type: USB IRP Info (0xfe) Packet Data Length: 0 The device responds with a proprietary response, with a different source 3.5.127: USB URB [Source: 3.5.127] [Destination: host] USBPcap pseudoheader length: 27 IRP ID: 0xfffffa80073ee120 IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) URB Function: URB_FUNCTION_ABORT_PIPE (0x0002) IRP information: 0x01, Direction: PDO -> FDO 0000 000. = Reserved: 0x00 .... ...1 = Direction: PDO -> FDO (0x1) URB bus id: 3 Device address: 5 Endpoint: 0xff, Direction: IN 1... .... = Direction: IN (1) .... 1111 = Endpoint number: 15 URB transfer type: Unknown (0xff) [Expert Info (Error/Malformed): USBPcap did not recognize URB Function code (report to desowin.org/USBPcap)] [USBPcap did not recognize URB Function code (report to desowin.org/USBPcap)] [Severity level: Error] [Group: Malformed] Packet Data Length: 0 Immediately after that the device re-connects as 3.6.0 and reports its USB2.0 description: DEVICE DESCRIPTOR bLength: 18 bDescriptorType: 0x01 (DEVICE) bcdUSB: 0x0200 bDeviceClass: Device (0x00) bDeviceSubClass: 0 bDeviceProtocol: 0 (Use class code info from Interface Descriptors) bMaxPacketSize0: 64 idVendor: Creative Technology, Ltd (0x041e) idProduct: Unknown (0x30d7) bcdDevice: 0x0100 iManufacturer: 1 iProduct: 2 iSerialNumber: 3 bNumConfigurations: 1 This is a regular USB-audio device which works OK in snd-usb-audio, as tested after rebooting from windows to linux. Please is there any similar case handled by the existing alsa usb driver which we could try to modify and test? My USB skills are not up to writing the required code myself from scratch, unfortunately. Thanks a lot, Pavel.

2 3

no_period_wakeup, axfer and --sched-model=timer
by Amadeusz Sławiński 13 May '21

13 May '21

Hi, I was checking some stuff relater to NO_PERIOD_WAKEUP and noticed that axfer has support for using either --sched-model=irq or --sched-model=timer. However from few quick tests it seems like it doesn't work? $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 When using --sched-model=irq it transfers data until I press Ctrl+C $ axfer transfer playback --sched-model=irq -D hw:0,0 -r 48000 -c2 -f S16_LE /dev/urandom PLAYBACK: Format 'Signed 16 bit Little Endian', Rate 48000 Hz, Channels 'Stereo' ^CPLAYBACK: Expected 4611686018427387903frames, Actual 163960frames Aborted by signal: Interrupt However with --sched-model=timer it time outs by itself: $ axfer transfer playback --sched-model=timer -D hw:0,0 -r 48000 -c2 -f S16_LE /dev/urandom PLAYBACK: Format 'Signed 16 bit Little Endian', Rate 48000 Hz, Channels 'Stereo' Fail to process frames: Connection timed out PLAYBACK: Expected 4611686018427387903frames, Actual 16304frames How well is NO_PERIOD_WAKEUP tested/supported? Is it a bug in axfer or perhaps some issue in kernel code? From some debugging I did, I have my suspicions that it gets stuck on poll in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sou… waiting for runtime->sleep to wake it, but seems like it never happens. What do you think? Amadeusz

3 5

alsa-lib dmix segfault; latest Git
by Mark Hills 13 May '21

13 May '21

The current Git master looks very broken, segfaulting immediately. It seems to be caused by commit 27f4a85a95 ("pcm: direct - move the direct struct init to _snd_pcm_direct_new()") Here's the trace: $ aplay -D plug:master testing.wav Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7f14ea6 in snd_pcm_dmix_open (pcmp=0x7fffffffe170, name=0x0, opts=0x7fffffffdef0, params=0x7fffffffdf30, root=0x43b1e0, sconf=0x455ae0, stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm_dmix.c:1017 1017 pcm->ops = &snd_pcm_dmix_ops; (gdb) bt #0 0x00007ffff7f14ea6 in snd_pcm_dmix_open (pcmp=0x7fffffffe170, name=0x0, opts=0x7fffffffdef0, params=0x7fffffffdf30, root=0x43b1e0, sconf=0x455ae0, stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm_dmix.c:1017 #1 0x00007ffff7f15763 in _snd_pcm_dmix_open (pcmp=0x7fffffffe170, name=0x0, root=0x43b1e0, conf=0x43b620, stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm_dmix.c:1374 #2 0x00007ffff7ec72d8 in snd_pcm_open_conf (pcmp=0x7fffffffe170, name=0x0, pcm_root=0x43b1e0, pcm_conf=0x43b620, stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm.c:2609 #3 0x00007ffff7ec7a1b in snd1_pcm_open_named_slave (pcmp=0x7fffffffe170, name=0x0, root=0x43b1e0, conf=0x43b620, stream=SND_PCM_STREAM_PLAYBACK, mode=0, parent_conf=0x43c390) at pcm.c:2823 #4 0x00007ffff7ee38a3 in snd_pcm_open_slave (pcmp=0x7fffffffe170, root=0x43b1e0, conf=0x43b620, stream=SND_PCM_STREAM_PLAYBACK, mode=0, parent_conf=0x43c390) at pcm_local.h:1008 #5 0x00007ffff7ee87a3 in _snd_pcm_route_open (pcmp=0x7fffffffe420, name=0x43cc50 "master", root=0x43b1e0, conf=0x43c390, stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm_route.c:1367 #6 0x00007ffff7ec72d8 in snd_pcm_open_conf (pcmp=0x7fffffffe420, name=0x43cc50 "master", pcm_root=0x43b1e0, pcm_conf=0x43c390, stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm.c:2609 #7 0x00007ffff7ec7547 in snd_pcm_open_noupdate (pcmp=0x7fffffffe420, root=0x43b1e0, name=0x43cc50 "master", stream=SND_PCM_STREAM_PLAYBACK, mode=0, hop=1) at pcm.c:2668 #8 0x00007ffff7ec79f4 in snd1_pcm_open_named_slave (pcmp=0x7fffffffe420, name=0x0, root=0x43b1e0, conf=0x43c320, stream=SND_PCM_STREAM_PLAYBACK, mode=0, parent_conf=0x43d120) at pcm.c:2821 #9 0x00007ffff7ef57ba in snd_pcm_open_slave (pcmp=0x7fffffffe420, root=0x43b1e0, conf=0x43c320, stream=SND_PCM_STREAM_PLAYBACK, mode=0, parent_conf=0x43d120) at pcm_local.h:1008 #10 0x00007ffff7ef824e in _snd_pcm_plug_open (pcmp=0x413768 <handle>, name=0x7fffffffebbb "plug:master", root=0x43b1e0, conf=0x43d120, stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm_plug.c:1324 #11 0x00007ffff7ec72d8 in snd_pcm_open_conf (pcmp=0x413768 <handle>, name=0x7fffffffebbb "plug:master", pcm_root=0x43b1e0, pcm_conf=0x43d120, stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm.c:2609 #12 0x00007ffff7ec7547 in snd_pcm_open_noupdate (pcmp=0x413768 <handle>, root=0x43b1e0, name=0x7fffffffebbb "plug:master", stream=SND_PCM_STREAM_PLAYBACK, mode=0, hop=0) at pcm.c:2668 #13 0x00007ffff7ec7610 in snd_pcm_open (pcmp=0x413768 <handle>, name=0x7fffffffebbb "plug:master", stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm.c:2698 #14 0x00000000004054ab in main (argc=4, argv=0x7fffffffe898) at aplay.c:850 -- Mark

2 1

pulse.conf overrides ~/.asoundrc for default
by GitHub issues - edited 13 May '21

13 May '21

alsa-project/alsa-lib issue #134 was edited from flatmax: On many systems pulse audio sets the default device to pulse. This overrides the settings in ~/.asoundrc. This is further complicated by using a tool like pasuspender and finding that pulse's default device is still set and overriding ~/.asoundrc It would seem more empowering to let the user override the default device in ~/.asoundrc and have that take effect over pulse.conf which typically resides in /usr/share/alsa/alsa.conf.d For that matter, it would be more empowering to the user to override everything (well almost any thing) using ~/.asoundrc, whether it is in alsa,conf.d or elsewhere. Issue URL : https://github.com/alsa-project/alsa-lib/issues/134 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

pulse.conf overrides ~/.asoundrc for default
by GitHub issues - edited 13 May '21

13 May '21

alsa-project/alsa-lib issue #134 was edited from flatmax: On many systems pulse audio sets the default device to pulse. This overrides the settings in ~/.asoundrc. This is further complicated by using a tool like pasuspender and finding that pulse's default device is still set and overriding ~/.asoundrc It would seem more empowering to let the user override the default device in ~/.asoundrc and have that take effect over pulse.conf which typically resides in /usr/share/alsa/alsa.conf.d For that matter, it would be more empowering to the user to override anything using ~/.asoundrc, whether it is in alsa,conf.d or elsewhere. Issue URL : https://github.com/alsa-project/alsa-lib/issues/134 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

pulse.conf overrides ~/.asoundrc for default
by GitHub issues - edited 13 May '21

13 May '21

alsa-project/alsa-lib issue #134 was edited from flatmax: On many systems pulse audio sets the default device to pulse. This overrides the settings in ~/.asoundrc. This is further complicated by using a tool like pasuspender and finding that pulse's default device is still set and overriding ~/.asoundrc It would seem more empowering to let the user override the default device in ~/.asoundrc and have that take effect over pulse.conf which typically resides in /usr/share/alsa/alsa.conf.d Issue URL : https://github.com/alsa-project/alsa-lib/issues/134 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

pulse.conf overrides ~/.asoundrc for default
by GitHub issues - opened 13 May '21

13 May '21

alsa-project/alsa-lib issue #134 was opened from flatmax: On many systems pulse audio sets the default device to pulse. This overrides the settings in ~/.asoundrc. This is further complicated by using a tool like pasuspender and finding that pulse's default device is still set and overriding ~/.asoundrc It would seem more empowering to let the user override the default device in ~/.asoundrc and have that take effect over pulse.conf which resides in /usr/share/alsa/alsa.conf.d Issue URL : https://github.com/alsa-project/alsa-lib/issues/134 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

re: ASoC: q6dsp: q6afe: remove unneeded dead-store initialization
by Colin Ian King 13 May '21

13 May '21

Hi, Static analysis with Coverity on linux-next has detected an issue with the following commit: commit 5f1b95d08de712327e452d082a50fded435ec884 Author: Yang Li <yang.lee(a)linux.alibaba.com> Date: Sun Apr 25 18:12:33 2021 +0800 ASoC: q6dsp: q6afe: remove unneeded dead-store initialization the analysis is as follows: 1181 int q6afe_port_stop(struct q6afe_port *port) 1182 { 1183 struct afe_port_cmd_device_stop *stop; 1184 struct q6afe *afe = port->afe; 1185 struct apr_pkt *pkt; 1. var_decl: Declaring variable port_id without initializer. 1186 int port_id; 1187 int ret = 0; 1188 int index, pkt_size; 1189 void *p; 1190 1191 index = port->token; 2. Condition index < 0, taking false branch. 3. Condition index >= 127, taking false branch. 1192 if (index < 0 || index >= AFE_PORT_MAX) { 1193 dev_err(afe->dev, "AFE port index[%d] invalid!\n", index); 1194 return -EINVAL; 1195 } 1196 1197 pkt_size = APR_HDR_SIZE + sizeof(*stop); 1198 p = kzalloc(pkt_size, GFP_KERNEL); 4. Condition !p, taking false branch. 1199 if (!p) 1200 return -ENOMEM; 1201 1202 pkt = p; 1203 stop = p + APR_HDR_SIZE; 1204 1205 pkt->hdr.hdr_field = APR_HDR_FIELD(APR_MSG_TYPE_SEQ_CMD, 1206 APR_HDR_LEN(APR_HDR_SIZE), 1207 APR_PKT_VER); 1208 pkt->hdr.pkt_size = pkt_size; 1209 pkt->hdr.src_port = 0; 1210 pkt->hdr.dest_port = 0; 1211 pkt->hdr.token = index; 1212 pkt->hdr.opcode = AFE_PORT_CMD_DEVICE_STOP; Uninitialized scalar variable (UNINIT) 5. uninit_use: Using uninitialized value port_id. 1213 stop->port_id = port_id; 1214 stop->reserved = 0; the commit removed the initialization of port_id = port->id, and now we have a regression where stop->port_id is being assigned with a garbage uninitialized value in port_id. Perhaps the fix needs reverting. As it stands, I don't know why clang was reporting this as an error. Colin

2 1