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

Add some CLOVE SSIDs of ALC293
by Pshou 14 May '21

14 May '21

From: Pshou Sent: Friday, May 14, 2021 1:23 PM To: 'alsa-devel(a)alsa-project.org' <alsa-devel(a)alsa-project.org> Cc: Kailang <kailang(a)realtek.com>; 'Takashi Iwai' <tiwai(a)suse.de>; Steve Wang <chirowang(a)realtek.com> Subject: Add some CLOVE SSIDs of ALC293 Hi Alsa-devel ML: Can you help me add some source code to patch_realtek.c? Add some CLEVO SSID of alc293. Best regards Pshou

1 0

[PATCH -next] ALSA: gus: Replace unsafe strcpy() with strscpy()
by YueHaibing 14 May '21

14 May '21

Fix smatch warning: sound/isa/gus/gus_main.c:396 snd_gus_check_version() error: strcpy() 'card->longname' too large for 'card->shortname' (80 vs 32) Even if this is not a real bug since the longest length of card->longname now is 31, replace strcpy() with strscpy() in order to avoid possible future mistake. Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> --- sound/isa/gus/gus_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/isa/gus/gus_main.c b/sound/isa/gus/gus_main.c index b7518122a10d..7524ce5785de 100644 --- a/sound/isa/gus/gus_main.c +++ b/sound/isa/gus/gus_main.c @@ -384,7 +384,7 @@ static int snd_gus_check_version(struct snd_gus_card * gus) } } } - strcpy(card->shortname, card->longname); + strscpy(card->shortname, card->longname, sizeof(card->shortname)); gus->uart_enable = 1; /* standard GUSes doesn't have midi uart trouble */ snd_gus_init_control(gus); return 0; -- 2.17.1

2 1

[PATCH 0/5] ALSA: firewire: misc fixes
by Takashi Sakamoto 14 May '21

14 May '21

Hi, This patchset includes misc fixes for bebob, oxfw, dice, and firewire-lib modules. The most significant bug to be fixed was introduced by my work for AMDTP domain during 2019-2020. Takashi Sakamoto (5): ALSA: dice: fix stream format at middle sampling rate for Alesis iO 26 ALSA: bebob/oxfw: fix Kconfig entry for Mackie d.2 Pro ALSA: firewire-lib: fix check of jumbo payload ALSA: firewire-lib: fix calculation for size of IR context payload ALSA: firewire-lib: fix amdtp_packet tracepoints event in terms of packet_index sound/firewire/Kconfig | 4 +-- sound/firewire/amdtp-stream-trace.h | 6 ++--- sound/firewire/amdtp-stream.c | 42 +++++++++++++++++------------ sound/firewire/bebob/bebob.c | 2 +- sound/firewire/dice/dice-alesis.c | 2 +- sound/firewire/oxfw/oxfw.c | 1 - 6 files changed, 32 insertions(+), 25 deletions(-) -- 2.27.0

2 6

[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