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

[PATCH 0/3] alsa-gobject: misc fixes
by GitHub pull_request - edited 28 May '21

28 May '21

alsa-project/alsa-gobject pull request #59 was edited from takaswie: This patchset fixes some bugs below: * Ubuntu 19.10/i386 is EOL and no release is available for i386 architecture in Ubuntu project * Update Fedora version for CI environment * Wrong command is in install section of README ``` Takashi Sakamoto (3): correct install section in README fix workflow according to EOF of i386 ubuntu distribution update Fedora release for CI environment .github/workflows/build.yml | 83 +++++++++++++++++++------------------ README.rst | 2 +- 2 files changed, 43 insertions(+), 42 deletions(-) ``` Request URL : https://github.com/alsa-project/alsa-gobject/pull/59 Patch URL : https://github.com/alsa-project/alsa-gobject/pull/59.patch Repository URL: https://github.com/alsa-project/alsa-gobject

1 0

[PATCH 0/3] alsa-gobject: misc fixes
by GitHub pull_request - edited 28 May '21

28 May '21

alsa-project/alsa-gobject pull request #59 was edited from takaswie: This patchset fixes some bugs below: * Ubuntu 19.10/i386 is EOL and no release is available for i386 architecture in Ubuntu project * Wrong command is in install section of README ``` Takashi Sakamoto (2): correct install section in README fix workflow according to EOF of i386 ubuntu distribution .github/workflows/build.yml | 81 +++++++++++++++++++------------------ README.rst | 2 +- 2 files changed, 42 insertions(+), 41 deletions(-) ``` Request URL : https://github.com/alsa-project/alsa-gobject/pull/59 Patch URL : https://github.com/alsa-project/alsa-gobject/pull/59.patch Repository URL: https://github.com/alsa-project/alsa-gobject

1 0

[PATCH 0/2] alsa-gobject: misc fixes
by GitHub pull_request - opened 28 May '21

28 May '21

alsa-project/alsa-gobject pull request #59 was opened from takaswie: This patchset fixes some bugs below: * Ubuntu 19.10/i386 is EOL and no release is available for i386 architecture in Ubuntu project * Wrong command is in install section of README ``` Takashi Sakamoto (2): correct install section in README fix workflow according to EOF of i386 ubuntu distribution .github/workflows/build.yml | 81 +++++++++++++++++++------------------ README.rst | 2 +- 2 files changed, 42 insertions(+), 41 deletions(-) ``` Request URL : https://github.com/alsa-project/alsa-gobject/pull/59 Patch URL : https://github.com/alsa-project/alsa-gobject/pull/59.patch Repository URL: https://github.com/alsa-project/alsa-gobject

1 0

[PATCH 0/3] ALSA: firewire-lib: preparation for media clock recovery
by Takashi Sakamoto 28 May '21

28 May '21

Hi, ALSA IEC 61883-1/6 packet streaming engine have been using pre-computed parameters ideal for nominal sampling transfer frequency (STF), to transfer packets to device since it was added 2011. As a result of user experience for a decade, it is clear that the sequence is not suitable to some actual devices. In design of audio and music unit in IEEE 1394 bus, feedback of effective sampling transfer frequency is delivered by packets transferred from device. Reuse of the sequence of parameter in the packets results in pseudo media clock recovery to transfer packet. In this patchset, an option is added to AMDTP domain so that each of AMDTP stream for outgoing packet has association to AMDTP stream for incoming packet, to replay the sequence of parameter. Some devices require receiving packet on-the-fly to transfer packets, so another option is added. These options are just added, not used yet in this time. In future work, they are going to be used by drivers in ALSA firewire stack. Takashi Sakamoto (3): ALSA: firewire-lib: add replay target to cache sequence of packet ALSA: firewire-lib: replay sequence of incoming packets for outgoing packets ALSA: firewire-lib: transfer rx packets on-the-fly when replaying sound/firewire/amdtp-stream.c | 252 ++++++++++++++++++-- sound/firewire/amdtp-stream.h | 17 +- sound/firewire/bebob/bebob_stream.c | 2 +- sound/firewire/dice/dice-stream.c | 2 +- sound/firewire/digi00x/digi00x-stream.c | 2 +- sound/firewire/fireface/ff-stream.c | 2 +- sound/firewire/fireworks/fireworks_stream.c | 2 +- sound/firewire/motu/motu-stream.c | 2 +- sound/firewire/oxfw/oxfw-stream.c | 2 +- sound/firewire/tascam/tascam-stream.c | 2 +- 10 files changed, 259 insertions(+), 26 deletions(-) -- 2.27.0

2 4

[PATCH] ALSA: firewire-lib: support NO_PERIOD_WAKEUP in ALSA PCM runtime
by Takashi Sakamoto 28 May '21

28 May '21

Drivers of ALSA firewire stack can process packets for IT/IR context in process context when the process operates ALSA PCM character device by calling ioctl(2) with some requests. The ioctl requests are: * SNDRV_PCM_IOCTL_HWSYNC * SNDRV_PCM_IOCTL_SYNC_PTR * SNDRV_PCM_IOCTL_REWIND * SNDRV_PCM_IOCTL_FORWARD * SNDRV_PCM_IOCTL_WRITEI_FRAMES * SNDRV_PCM_IOCTL_READI_FRAMES * SNDRV_PCM_IOCTL_WRITEN_FRAMES * SNDRV_PCM_IOCTL_READN_FRAMES This means that general application can process PCM frames apart from hardware IRQ invocation, even if they are programmed by either IRQ-based scheduling model or Timer-based scheduling model. This commit add support for Timer-based scheduling model by allowing PCM runtime to suppress both process wakeup per period and scheduling hardware IRQ. SNDRV_PCM_INFO_BATCH is obsoleted since ALSA IEC 61883-1/6 packet streaming engine can report the number of transferred PCM frames within PCM period boundary. The granularity equals to SYT_INTERVAL in blocking transmission. In non-blocking transmission, it doesn't equal to SYT_INTERVAL but doesn't exceed. This patch is tested with PulseAudio, and --sched-model option of axfer with fix against the issue reported at: * https://lore.kernel.org/alsa-devel/687f9871-7484-1370-04d1-9c968e86f72b@lin… Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/amdtp-stream.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/sound/firewire/amdtp-stream.c b/sound/firewire/amdtp-stream.c index 68ffbc33f692..8e72e7f4c082 100644 --- a/sound/firewire/amdtp-stream.c +++ b/sound/firewire/amdtp-stream.c @@ -191,14 +191,13 @@ int amdtp_stream_add_pcm_hw_constraints(struct amdtp_stream *s, unsigned int maximum_usec_per_period; int err; - hw->info = SNDRV_PCM_INFO_BATCH | - SNDRV_PCM_INFO_BLOCK_TRANSFER | + hw->info = SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_JOINT_DUPLEX | SNDRV_PCM_INFO_MMAP | - SNDRV_PCM_INFO_MMAP_VALID; + SNDRV_PCM_INFO_MMAP_VALID | + SNDRV_PCM_INFO_NO_PERIOD_WAKEUP; - /* SNDRV_PCM_INFO_BATCH */ hw->periods_min = 2; hw->periods_max = UINT_MAX; @@ -503,7 +502,12 @@ static void update_pcm_pointers(struct amdtp_stream *s, s->pcm_period_pointer += frames; if (s->pcm_period_pointer >= pcm->runtime->period_size) { s->pcm_period_pointer -= pcm->runtime->period_size; - queue_work(system_highpri_wq, &s->period_work); + + // The program in user process should periodically check the status of intermediate + // buffer associated to PCM substream to process PCM frames in the buffer, instead + // of receiving notification of period elapsed by poll wait. + if (!pcm->runtime->no_period_wakeup) + queue_work(system_highpri_wq, &s->period_work); } } @@ -949,6 +953,7 @@ static void process_rx_packets(struct fw_iso_context *context, u32 tstamp, size_ unsigned int event_count = s->ctx_data.rx.event_count; unsigned int pkt_header_length; unsigned int packets; + bool need_hw_irq; int i; if (s->packet_index < 0) @@ -968,6 +973,16 @@ static void process_rx_packets(struct fw_iso_context *context, u32 tstamp, size_ else pkt_header_length = 0; + if (s == d->irq_target) { + // At NO_PERIOD_WAKEUP mode, the packets for all IT/IR contexts are processed by + // the tasks of user process operating ALSA PCM character device by calling ioctl(2) + // with some requests, instead of scheduled hardware IRQ of an IT context. + struct snd_pcm_substream *pcm = READ_ONCE(s->pcm); + need_hw_irq = !pcm || !pcm->runtime->no_period_wakeup; + } else { + need_hw_irq = false; + } + for (i = 0; i < packets; ++i) { const struct pkt_desc *desc = s->pkt_descs + i; struct { @@ -984,7 +999,7 @@ static void process_rx_packets(struct fw_iso_context *context, u32 tstamp, size_ event_count += desc->data_blocks; if (event_count >= events_per_period) { event_count -= events_per_period; - sched_irq = true; + sched_irq = need_hw_irq; } } -- 2.27.0

2 1

No sound with Realtek ALC3306
by GitHub issues - edited 28 May '21

28 May '21

alsa-project/alsa-lib issue #139 was edited from dantahoua: Realtek ALC3306 (Lenovo 13s Gen2 ITL i7), but seems common problem with any computer using this codec. -Headphone, HDMI, BT working great. -Speaker not working (but computer seeing audio output and sending audio, meter even showing audio in GUI). Seems like something (amp?) is not turned, like missing something between speaker and codec... Works perfect in Windows 10. Tested lots different distro and kernel... Computer report ALC287 but it is not! It's ALC3306... Here is the alsa infos: [Infos](http://alsa-project.org/db/?f=1f3e847b60bd38085e39e26d992ea8680dd908… Issue URL : https://github.com/alsa-project/alsa-lib/issues/139 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

No sound with Realtek ALC3306
by GitHub issues - edited 28 May '21

28 May '21

alsa-project/alsa-lib issue #139 was edited from dantahoua: Realtek ALC3306 (Lenovo 13s Gen2 ITL i7), but seems common problem with any computer using this codec. -Headphone, HDMI, BT working great. -Speaker not working (but computer seeing audio output and sending audio, meter even showing audio in GUI). Seems like something (amp?) is not turned, like missing something between speaker and codec... Works perfect in Windows 10. Tested lots different distro and kernel... Here is the alsa infos: [Infos](http://alsa-project.org/db/?f=1f3e847b60bd38085e39e26d992ea8680dd908… Issue URL : https://github.com/alsa-project/alsa-lib/issues/139 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

No sound with Realtek ALC3306
by GitHub issues - opened 27 May '21

27 May '21

alsa-project/alsa-lib issue #139 was opened from dantahoua: Realtek ALC3306 (Lenovo 13s Gen2 ITL i7), but seems common problem with any computer using this codec. -Headphone, HDMI, BT working great. -Speaker not working (but computer seeing audio output and sending audio, meter even showing audio in GUI). Seems like something (amp?) is not turned, like missing something between speaker and codec... Works perfect in Windows 10. Tested lots different distro and kernel... Issue URL : https://github.com/alsa-project/alsa-lib/issues/139 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH v4 0/3] Unify NVIDIA Tegra ASoC machine drivers
by Dmitry Osipenko 27 May '21

27 May '21

This series squashes all the ASoC machine drivers into a single one, this change was suggested by Jon Hunter. It also sets driver_name and components string of each card, allowing userspace alsa-lib to find UCMs at predictable path. Changelog: v4: - Moved out mclk_rate callback that is currently used only by WM8903 machine driver from the common driver. This was suggested by Jon Hunter. - Dropped patch which was setting custom components string for Nexus 7. Jaroslav Kysela wants it to be specified in a device-tree, but the components string doesn't have a firm specification for today. It's better to drop this change for now since it's optional anyways. - Fixed compilation error that was reported by kernel robot for v3. - Jaroslav Kysela merged alsa-ucm-conf PR [1] which added UCMs for Nexus 7 and Acer A500. The UCMs are fully working using a combination of updated kernel + alsa-ucm-conf master + alsa-lib master, meaning that they will work with the next releases of kernel and ALSA userspace upstream packages. - Added ack from Jaroslav Kysela to the "Specify components string for each card" patch that he gave to v3. v3: - Added components string as was suggested by Jaroslav Kysela to v2. - Renamed MCLK rate function that is used by max98090 and other codecs to make it look more generic. Added option for specifying CLK ID per device. This all was suggested by Jon Hunter to v2. v2: - Dropped use of of_device_compatible_match(), like it was suggested by Rob Herring in a review comment to v1. - Added patch that sets card's driver_name of as Tegra ASoC drivers. In a comment to v1 Jaroslav Kysela suggested that the Tegra drivers don't set the card name properly and he was right. I opened pull request with the new Tegra UCMs and updated lookup paths for older UCMs [1]. [1] https://github.com/alsa-project/alsa-ucm-conf/pull/92 Dmitry Osipenko (3): ASoC: tegra: Set driver_name=tegra for all machine drivers ASoC: tegra: Unify ASoC machine drivers ASoC: tegra: Specify components string for each card sound/soc/tegra/Kconfig | 12 + sound/soc/tegra/Makefile | 18 +- sound/soc/tegra/tegra_alc5632.c | 259 ---------- sound/soc/tegra/tegra_asoc_machine.c | 714 +++++++++++++++++++++++++++ sound/soc/tegra/tegra_asoc_machine.h | 46 ++ sound/soc/tegra/tegra_max98090.c | 276 ----------- sound/soc/tegra/tegra_rt5640.c | 222 --------- sound/soc/tegra/tegra_rt5677.c | 324 ------------ sound/soc/tegra/tegra_sgtl5000.c | 211 -------- sound/soc/tegra/tegra_wm8753.c | 185 ------- sound/soc/tegra/tegra_wm8903.c | 351 +++---------- sound/soc/tegra/tegra_wm9712.c | 166 ------- sound/soc/tegra/trimslice.c | 172 ------- 13 files changed, 853 insertions(+), 2103 deletions(-) delete mode 100644 sound/soc/tegra/tegra_alc5632.c create mode 100644 sound/soc/tegra/tegra_asoc_machine.c create mode 100644 sound/soc/tegra/tegra_asoc_machine.h delete mode 100644 sound/soc/tegra/tegra_max98090.c delete mode 100644 sound/soc/tegra/tegra_rt5640.c delete mode 100644 sound/soc/tegra/tegra_rt5677.c delete mode 100644 sound/soc/tegra/tegra_sgtl5000.c delete mode 100644 sound/soc/tegra/tegra_wm8753.c delete mode 100644 sound/soc/tegra/tegra_wm9712.c delete mode 100644 sound/soc/tegra/trimslice.c -- 2.30.2

1 3

Internal microphone does not work with 5.12 (Tiger Lake, X1 Nano)
by Nico Schottelius 27 May '21

27 May '21

Hello, it seems that the internal microphone does not work anymore with 5.12.6/5.12.7. I am somewhat sure it used to work within the 5.11.x series and that sound did not work at all on 5.10. I have uploaded the hardware information on http://alsa-project.org/db/?f=f1a2b32db122695b2cf736db27cb6ed2fa8a9042 The microphone of a plugged in headset however *does* work. Is this a known bug/regression and is there anything I can do to debug it? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

4 8