April 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] snd-usb-audio Buffer Sizes and Round Trip Latency
by Jonathan Liu 30 Apr '19

30 Apr '19

Hi, I want to start a discussion regarding round trip latency for class compliant USB audio interfaces on Linux. In particular, I am noticing with my USB 2.0 RME Babyface Pro audio interface that the round trip latency is considerably higher on Linux than on macOS High Sierra and Windows 10. I tested the round trip latency using a loopback audio cable and the ReaInsert plugin included with Reaper DAW (www.reaper.fm) that can be downloaded for Windows/macOS/Linux to calculate the additional delay. Here are the results for 48000 Hz, 24-bit on my RME Babyface Pro: === block_size/periods block_size*periods + additional_delay ~ round_trip_latency round_trip_latency = (block_size*periods + additional_delay) / 48000 * 1000 Linux 4.17.14, Class Compliant Mode (snd-usb-audio, ALSA backend): 16/2 32 + 80 ~ 2.333 ms 16/3 48 + 109 ~ 3.271 ms 32/2 64 + 129 ~ 4.021 ms 32/3 96 + 166 ~ 5.458 ms 64/2 128 + 205 ~ 6.938 ms 64/3 192 + 242 ~ 9.042 ms 128/2 256 + 352 ~ 12.667 ms 128/3 384 + 496 ~ 18.334 ms 256/2 512 + 650 ~ 24.208 ms 256/3 768 + 650 ~ 29.542 ms 512/2 1024 + 634 ~ 34.542 ms 512/3 1536 + 634 ~ 45.208 ms 1024/2 2048 + 650 ~ 56.208 ms 1024/3 3072 + 650 ~ 77.542 ms 2048/2 4096 + 633 ~ 98.521 ms 2048/3 6144 + 633 ~ 141.188 ms macOS High Sierra, Class Compliant Mode (Apple Driver): 16/2 32 + 205 ~ 4.938 ms 32/2 64 + 205 ~ 5.604 ms 64/2 128 + 205 ~ 6.938 ms 128/2 256 + 205 ~ 9.604 ms 256/2 512 + 205 ~ 14.938 ms 512/2 1024 + 205 ~ 25.604 ms 1024/2 2048 + 205 ~ 46.938 ms 2048/2 4096 + 205 ~ 89.604 ms macOS High Sierra, PC Mode (RME Driver v3.08): 16/2 32 + 59 ~ 1.896 ms 32/2 64 + 59 ~ 2.563 ms 64/2 128 + 59 ~ 3.896 ms 128/2 256 + 59 ~ 6.563 ms 256/2 512 + 59 ~ 11.596 ms 512/2 1024 + 59 ~ 22.563 ms 1024/2 2048 + 59 ~ 43.896 ms 2048/2 4096 + 59 ~ 86.563 ms Windows 10, PC Mode (RME Driver 1.099): 48/2 96 + 63 ~ 3.313 ms 64/2 128 + 63 ~ 3.979 ms 96/2 192 + 63 ~ 5.313 ms 128/2 256 + 63 ~ 6.646 ms 256/2 512 + 63 ~ 11.979 ms 512/2 1024 + 63 ~ 22.646 ms 1024/2 2048 + 63 ~ 43.979 ms 2048/2 4096 + 63 ~ 86.646 ms === Some things in particular I noticed on Linux: - additional_delay varies a bit if I close and open the audio device again - additional_delay seems to increase as the block_size increases. I can make the additional_delay stay about the same rather than increasing by setting MAX_PACKS and MAX_PACKS_HS to 1 in sound/usb/card.h. In Linux versions before 3.13 there was a nrpacks parameter for snd-usb-audio to control this but it was removed with commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… - additional_delay is not constant as block_size is increased like on macOS and Windows I made a patch to snd-usb-audio to expose the snd-usb-audio constants as runtime adjustable module parameters (/sys/module/snd_usb_audio/parameters/) for testing (takes effect when the device is disconnected+reconnected and logs the parameter values to dmesg): https://aur.archlinux.org/cgit/aur.git/plain/parameters.patch?h=snd-usb-aud… The patch is used in my Arch Linux AUR package for convenience (using DKMS to avoid having to recompile entire kernel): https://aur.archlinux.org/packages/snd-usb-audio-lowlatency-dkms/ Can snd-usb-audio be improved so the additional_delay is always the same when closing/opening/reconfiguring the audio device and does not increase as the block_size increases? I noticed using USB audio on Linux at lower latencies (block_size <= 128) is more prone to audio dropouts under load compared to macOS and Windows, even with CPU power management disabled (writing 0 to /dev/cpu_dma_latency). What can be done about this? Thanks. Regards, Jonathan

4 11

[alsa-devel] [PATCH] ALSA: hda - Register irq handler after the chip initialization
by Takashi Iwai 30 Apr '19

30 Apr '19

Currently the IRQ handler in HD-audio controller driver is registered before the chip initialization. That is, we have some window opened between the azx_acquire_irq() call and the CORB/RIRB setup. If an interrupt is triggered in this small window, the IRQ handler may access to the uninitialized RIRB buffer, which leads to a NULL dereference Oops. This is usually no big problem since most of Intel chips do register the IRQ via MSI, and we've already fixed the order of the IRQ enablement and the CORB/RIRB setup in the former commit b61749a89f82 ("sound: enable interrupt after dma buffer initialization"), hence the IRQ won't be triggered in that room. However, some platforms use a shared IRQ, and this may allow the IRQ trigger by another source. Another possibility is the kdump environment: a stale interrupt might be present in there, the IRQ handler can be falsely triggered as well. For covering this small race, let's move the azx_acquire_irq() call after hda_intel_init_chip() call. Although this is a bit radical change, it can cover more widely than checking the CORB/RIRB setup locally in the callee side. Reported-by: Liwei Song <liwei.song(a)windriver.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 2ec91085fa3e..789308f54785 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1788,9 +1788,6 @@ static int azx_first_init(struct azx *chip) chip->msi = 0; } - if (azx_acquire_irq(chip, 0) < 0) - return -EBUSY; - pci_set_master(pci); synchronize_irq(bus->irq); @@ -1904,6 +1901,9 @@ static int azx_first_init(struct azx *chip) return -ENODEV; } + if (azx_acquire_irq(chip, 0) < 0) + return -EBUSY; + strcpy(card->driver, "HDA-Intel"); strlcpy(card->shortname, driver_short_names[chip->driver_type], sizeof(card->shortname)); -- 2.16.4

1 0

[alsa-devel] [PATCH] ALSA: hda: check RIRB to avoid use NULL pointer
by Song liwei 30 Apr '19

30 Apr '19

From: Liwei Song <liwei.song(a)windriver.com> Fix the following BUG: BUG: unable to handle kernel NULL pointer dereference at 000000000000000c Workqueue: events azx_probe_work [snd_hda_intel] RIP: 0010:snd_hdac_bus_update_rirb+0x80/0x160 [snd_hda_core] Call Trace: <IRQ> azx_interrupt+0x78/0x140 [snd_hda_codec] __handle_irq_event_percpu+0x49/0x300 handle_irq_event_percpu+0x23/0x60 handle_irq_event+0x3c/0x60 handle_edge_irq+0xdb/0x180 handle_irq+0x23/0x30 do_IRQ+0x6a/0x140 common_interrupt+0xf/0xf The Call Trace happened when run kdump on a NFS rootfs system. Exist the following calling sequence when boot the second kernel: azx_first_init() --> azx_acquire_irq() <-- interrupt come in, azx_interrupt() was called --> hda_intel_init_chip() --> azx_init_chip() --> snd_hdac_bus_init_chip() --> snd_hdac_bus_init_cmd_io(); --> init rirb.buf and corb.buf Interrupt happened after azx_acquire_irq() while RIRB still didn't got initialized, then NULL pointer will be used when process the interrupt. Check the value of RIRB to ensure it is not NULL, to aviod some special case may hang the system. Fixes: 14752412721c ("ALSA: hda - Add the controller helper codes to hda-core module") Signed-off-by: Liwei Song <liwei.song(a)windriver.com> --- sound/hda/hdac_controller.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c index 74244d8e2909..2f0fa5353361 100644 --- a/sound/hda/hdac_controller.c +++ b/sound/hda/hdac_controller.c @@ -195,6 +195,9 @@ void snd_hdac_bus_update_rirb(struct hdac_bus *bus) return; bus->rirb.wp = wp; + if (!bus->rirb.buf) + return; + while (bus->rirb.rp != wp) { bus->rirb.rp++; bus->rirb.rp %= AZX_MAX_RIRB_ENTRIES; -- 2.7.4

3 5

[alsa-devel] [GIT PULL] soundwire updates for v5.2-rc1
by Vinod Koul 30 Apr '19

30 Apr '19

Hey Greg, Please PULL to receive updates to soundwire subsystem The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git tags/soundwire-5.2-rc1 for you to fetch changes up to 4abbd783d126cabfc20d1b8d50b1d5026b5cba09: soundwire: intel: fix implicit header use of module.h/export.h (2019-04-14 15:52:50 +0530) ---------------------------------------------------------------- soundwire updates for v5.2-rc1 This round saw interest from Intel, Linaro and Cadence in Soundwire. More patches are in pipeline (maybe next cycle) - removal of useless initialzation in core - couple of header and kcalloc inversion fixes on Intel driver ---------------------------------------------------------------- Paul Gortmaker (1): soundwire: intel: fix implicit header use of module.h/export.h Pierre-Louis Bossart (3): soundwire: intel: fix inversion in devm_kcalloc parameters soundwire: remove useless initializations soundwire: stream: remove useless initialization of local variable drivers/soundwire/bus.c | 2 -- drivers/soundwire/intel.c | 5 +++-- drivers/soundwire/intel_init.c | 2 ++ drivers/soundwire/stream.c | 2 +- 4 files changed, 6 insertions(+), 5 deletions(-) Thanks -- ~Vinod

3 4

[alsa-devel] move eapd coef function before ACT_PRE_PROBE state
by Kailang 30 Apr '19

30 Apr '19

Hi Takashi, alc_fill_eapd_coef(),this function was change EAPD control to default. Default was set EAPD by verb control. This function was run in ACT_INIT state. Move it to ACT_PRE_PROBE above. It will have a chance to change EAPD control on ACT_PRE_PROBE state. It could change control by 0x20 coef bit. BR, Kailang

2 1

Re: [alsa-devel] ALC892 acquisition stutter
by Takashi Iwai 30 Apr '19

30 Apr '19

On Tue, 30 Apr 2019 08:27:54 +0200, rodomar705(a)protonmail.com wrote: > > Nope, neither adding AZX_DCAPS_PM_RUNTIME as seen on other AMD codecs below seems to affect it, unfortunately. Please don't drop Cc to ML and others. And, did you try other position_fix option value, too? Otherwise I have out of idea. It must be platform-specific issue only the hardware vendors know. Takashi > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > Il lunedì 29 aprile 2019 21:28, Takashi Iwai <tiwai(a)suse.de> ha scritto: > > > On Mon, 29 Apr 2019 20:21:22 +0200, > > rodomar705(a)protonmail.com wrote: > > > > > Whoops, sorry. Here it is. > > > > OK, it's an AMD chip and not listed explicitly in the driver config. > > Does the patch below have any influence? > > > > Takashi > > > > --- a/sound/pci/hda/hda_intel.c > > +++ b/sound/pci/hda/hda_intel.c > > @@ -2452,6 +2452,9 @@ static const struct pci_device_id azx_ids[] = { > > /* AMD Hudson */ > > { PCI_DEVICE(0x1022, 0x780d), > > .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, > > > > - /* AMD family 17h */ > > - { PCI_DEVICE(0x1022, 0x1457), > > - .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, > > > > > > /* AMD Stoney */ > > { PCI_DEVICE(0x1022, 0x157a), > > .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB | > > > >

1 0

Re: [alsa-devel] ALC892 acquisition stutter
by Takashi Iwai 29 Apr '19

29 Apr '19

On Mon, 29 Apr 2019 20:21:22 +0200, rodomar705(a)protonmail.com wrote: > > Whoops, sorry. Here it is. OK, it's an AMD chip and not listed explicitly in the driver config. Does the patch below have any influence? Takashi --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2452,6 +2452,9 @@ static const struct pci_device_id azx_ids[] = { /* AMD Hudson */ { PCI_DEVICE(0x1022, 0x780d), .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, + /* AMD family 17h */ + { PCI_DEVICE(0x1022, 0x1457), + .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, /* AMD Stoney */ { PCI_DEVICE(0x1022, 0x157a), .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB |

1 0

[alsa-devel] [PATCH] ASoC: Intel: avoid Oops if DMA setup fails
by Ross Zwisler 29 Apr '19

29 Apr '19

Currently in sst_dsp_new() if we get an error return from sst_dma_new() we just print an error message and then still complete the function successfully. This means that we are trying to run without sst->dma properly set up, which will result in NULL pointer dereference when sst->dma is later used. This was happening for me in sst_dsp_dma_get_channel(): struct sst_dma *dma = dsp->dma; ... dma->ch = dma_request_channel(mask, dma_chan_filter, dsp); This resulted in: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: sst_dsp_dma_get_channel+0x4f/0x125 [snd_soc_sst_firmware] Fix this by adding proper error handling for the case where we fail to set up DMA. Signed-off-by: Ross Zwisler <zwisler(a)google.com> Cc: stable(a)vger.kernel.org --- sound/soc/intel/common/sst-firmware.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/intel/common/sst-firmware.c b/sound/soc/intel/common/sst-firmware.c index 1e067504b6043..9be3a793a55e3 100644 --- a/sound/soc/intel/common/sst-firmware.c +++ b/sound/soc/intel/common/sst-firmware.c @@ -1251,11 +1251,15 @@ struct sst_dsp *sst_dsp_new(struct device *dev, goto irq_err; err = sst_dma_new(sst); - if (err) + if (err) { dev_warn(dev, "sst_dma_new failed %d\n", err); + goto dma_err; + } return sst; +dma_err: + free_irq(sst->irq, sst); irq_err: if (sst->ops->free) sst->ops->free(sst); -- 2.21.0.593.g511ec345e18-goog

3 4

Re: [alsa-devel] ALC892 acquisition stutter
by Takashi Iwai 29 Apr '19

29 Apr '19

On Mon, 29 Apr 2019 18:25:18 +0200, rodomar705(a)protonmail.com wrote: > > Sample formats or sample rates wasn't yielding anything useful, > unfortunately; nor the -D on the hardware. However, after setting > --buffer-size 8192 and --period-size to 32768 the clicking are > finally completely gone in arecord. The question remains on how to > set this two parameters permanently to force ALSA to use them, if > it's possible at all. (and I hope that they will not influence too > much the delay of the acquisition). This is a too big period size for normal use case. > On pulseaudio, no luck in any way. tsched=0 make the acquisition 10 > times worse, regardless of the latency_msec passed to the loopback > module that was the only "half fix", since to have clean audio I > need a latency of 1,25s, that for doing real time communication is > not really the ideal solution. If the smaller period size in arecord causes a problem, it's rather other way round; tsched=0 is for small periods but works with the inaccurate position reporting. OTOH, tsched=1 is basically with a huge single period in the buffer. So, if it were only about the period size, PA tsched=1 should have worked better. It means that something else plays another role. > snoop=0 changed nothing, > unfortunately, nor passing model=HDMI, generic to the codec (the > first codec on my system is an AMD GPU card, the second is the > integrated codec). For these kernel module parameters, double-check that they are properly applied. The snoop=0 should be seen in the dmesg output where the driver will tell the snoop mode change. And the generic model would lead to a different set of mixer elements, so you can compare the difference in "amixer contents" output. The fact that the period size matters implies that it *might* be a HD-audio controller problem, not the codec. Could you give alsa-info.sh output? Run with --no-upload option, and attach the output. If it's about the controller side, position_fix option might have some influence, too. Also, with any options, try to disable the runtime PM. At easiest, do echo 0 > /sys/module/snd_hda_intel/parameters/power_save" should disable the runtime PM temporarily. Takashi > Thanks a lot for the detailed email, > > I hope that someone will figure out what's causing this, > > Marco. > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > Il lunedì 29 aprile 2019 17:06, Takashi Iwai <tiwai(a)suse.de> ha scritto: > > > On Sun, 28 Apr 2019 11:34:34 +0200, > > rodomar705(a)protonmail.com wrote: > > > > > Maybe, just maybe, I found a probable cause of what's happening here. Since it was working with ALSA directly only with audacity, I follow the instruction on tracing the HDA commands sent to the codec while acquiring audio with Audacity. One with ALSA directly (just with Audacity thought, arecord show the same problem from Pulse), when is working correctly, one without it, using pulse. The logs are very interesting. > > > The working one just simply sent two command to the audio codec, and then the stream started. > > > The other one spammed a lot of more data, and it appears that the problem (and the continuous popping of the audio) derives from the fact that the codec keep closing the stream after 100 to 300 ms, that force pulse to ask the audio controller to restart the stream and cause an actual noise coming from the microphone (since the stream is not instantly restarted). > > > There is another little difference beetween the second command sent to the codec directly with ALSA (from audacity) and the command sent from Pulse: > > > ALSA with Audacity: > > > 1106.051129: hda_send_cmd: [0000:09:00.3:0] val=0x00820031 > > > Pulse with Audacity: > > > 1231.103757: hda_send_cmd: [0000:09:00.3:0] val=0x00820011 > > > However with arecord -d 10 -fS16_LE -r44100 /tmp/test-mic.wav as a parameter I still get almost the same as Pulseaudo: > > > arecord with Audacity: > > > 2891.230874: hda_send_cmd: [0000:09:00.3:0] val=0x00824011 > > > However, no start stop behaviour like on pulseaudio, however the audio clicking are still there. > > > The log are attached to this email, hoping that will help fix the issue. > > > > Basically there can be three or four different parameters that may > > bring difference easily. The most suspected ones are the sample rates > > and the sample formats. So, check the combination of -fS16_LE, > > -fS32_LE, -r44110 and -r48000 with arecord. At best, pass -Dhw:0 > > option (or hw:1, depending on the machine) to assure that no > > conversion is done in alsa-lib, and pass -c2 option for stereo. > > > > arecord -Dhw:0 -c2 -fS32_LE -r44100 foo.wav > > > > The next would be to check the period size and buffer size. You can > > specify them via --period-size and --buffer-size options of arecord. > > They are in frames unit, not in bytes. Try to use a small and a large > > period / buffer size to see whether they give any difference. > > > > Also, for PA side, you can try the following: > > > > - Disable timer-scheduling: if the HD-audio controller is buggy and > > the pointer updates aren't accurate, it's a problem with the timer > > scheduling mode used as default in PA. You can pass tsched=0 option > > somehow, see the PA documentation. > > > > - Try to not load Realtek codec driver but use the generic codec > > driver. For that, pass model=generic option to snd-hda-intel > > module. (If there are two HD-audio controllers, pass > > model=generic,generic instead.) > > > > - Try to disable snooping in HD-audio driver, pass snoop=0 option to > > snd-hda-intel module. I don't think this would matter, but it's > > been often a problem on a new chip on AMD or other platforms. > > > > HTH, > > > > Takashi > > > > > > > Sent with ProtonMail Secure Email. > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > Il domenica 28 aprile 2019 10:52, rodomar705(a)protonmail.com ha scritto: > > > > > > > Already sent to alsa-user, however a developer asked to send this also on devel, so here it is: > > > > I have audio stutters with an ALC892 Realtek Chipset on a B450 GAMING ELITE board from Gigabyte during acquisition (at least with microphone input, both front and back. Line in not tested). No issues with Windows. > > > > After opening an issue and testing with a PulseAudio developer, he has determined that the issue is not within PulseAudio, but on ALSA. > > > > There are already two issues about that on the bug tracker on Linux, namely this two: > > > > ALC892: https://bugzilla.kernel.org/show_bug.cgi?id=203351 > > > > ALC1220: https://bugzilla.kernel.org/show_bug.cgi?id=195303 > > > > To me both appears to be identical, for this reason even if I have a ALC892 I’ve posted on the second one, just because it had more posts. > > > > The particular thing is that acquiring with PulseAudio on Audacity show the problem, however using ALSA directly the issue is not present. Trying using arecord still present the issue from PulseAudio. > > > > Tried to play with the parameters /sys/devices/audio to no avail. Compared the pinconfigs from Windows, they are identical. > > > > Can someone try to help me fix the issue? > > > > Sent with ProtonMail Secure Email. > > > > [2 alsaaudacitylog <application/octet-stream (base64)>] > > > > > > [3 pulseaudacitylog <application/octet-stream (base64)>] > > > [4 arecordlog <application/octet-stream (base64)>] > > > > > > Alsa-devel mailing list > > > Alsa-devel(a)alsa-project.org > > > https://mailman.alsa-project.org/mailman/listinfo/alsa-devel > >

1 0

[alsa-devel] [PATCH v2] ALSA: usx2y: fix a double free bug
by Wenwen Wang 29 Apr '19

29 Apr '19

In usX2Y_In04_init(), a new urb is firstly created through usb_alloc_urb() and saved to 'usX2Y->In04urb'. Then, a buffer is allocated through kmalloc() and saved to 'usX2Y->In04Buf'. If the allocation of the buffer fails, the error code ENOMEM is returned after usb_free_urb(), which frees the created urb. However, the urb is actually freed at card->private_free callback, i.e., snd_usX2Y_card_private_free(). So the free operation here leads to a double free bug. To fix the above issue, simply remove usb_free_urb(). Signed-off-by: Wenwen Wang <wang6495(a)umn.edu> --- sound/usb/usx2y/usbusx2y.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/usb/usx2y/usbusx2y.c b/sound/usb/usx2y/usbusx2y.c index da4a5a5..1f0b0100 100644 --- a/sound/usb/usx2y/usbusx2y.c +++ b/sound/usb/usx2y/usbusx2y.c @@ -293,10 +293,8 @@ int usX2Y_In04_init(struct usX2Ydev *usX2Y) if (! (usX2Y->In04urb = usb_alloc_urb(0, GFP_KERNEL))) return -ENOMEM; - if (! (usX2Y->In04Buf = kmalloc(21, GFP_KERNEL))) { - usb_free_urb(usX2Y->In04urb); + if (! (usX2Y->In04Buf = kmalloc(21, GFP_KERNEL))) return -ENOMEM; - } init_waitqueue_head(&usX2Y->In04WaitQueue); usb_fill_int_urb(usX2Y->In04urb, usX2Y->dev, usb_rcvintpipe(usX2Y->dev, 0x4), -- 2.7.4

2 1