Add duplex sound support for USB devices using implicit feedback

For USB sound devices using implicit feedback the endpoint used for this feedback should be able to be opened twice, once for required feedback and second time for audio data. This way these devices can be put in duplex audio mode. Since this only works if the settings of the endpoint don't change a check is included for this.

This fixes bug 207023 ("MOTU M2 regression on duplex audio") and should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex")

Signed-off-by Erwin Burema <[email protected]>

For USB sound devices using implicit feedback the endpoint used for this feedback should be able to be opened twice, once for required feedback and second time for audio data. This way these devices can be put in duplex audio mode. Since this only works if the settings of the endpoint don't change a check is included for this.

This fixes bug 207023 ("MOTU M2 regression on duplex audio") and should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex")

Signed-off-by Erwin Burema <[email protected]>

---

В Вс, 10/05/2020 в 20:29 +0200, Erwin Burema пишет:

Quoted 10 lines

For USB sound devices using implicit feedback the endpoint used for this feedback should be able to be opened twice, once for required feedback and second time for audio data. This way these devices can be put in duplex audio mode. Since this only works if the settings of the endpoint don't change a check is included for this.

This fixes bug 207023 ("MOTU M2 regression on duplex audio") and should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex")

Quoted 2 lines

Signed-off-by Erwin Burema <[email protected]>

---

This patch seems to cause kernel panic on my system. This happens during boot when gdm (with pulseaudio) is starting up.

$ grep CONFIG_IRQ_FORCED_THREADING /boot/config-5.4.42-gentoo
CONFIG_IRQ_FORCED_THREADING=y

$ grep threadirqs /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.4.42-gentoo root=/dev/mapper/vg_system-root ro
rd.md.uuid=cdf11511:cf0ca8c5:cc165dc3:3d3d248f
rd.luks.uuid=a5a6e532-af4e-49b2-8178-95e54c293799 rd.lvm.lv=vg_system/root
rd.lvm.lv=vg_system/swap rd.lvm.lv=vg_system/usr
resume=/dev/mapper/vg_system-swap
rootflags=relatime,logbufs=8,logbsize=256k rootfstype=xfs
init=/lib/systemd/systemd noautogroup loglevel=5 console=ttyS1,115200
console=tty0 threadirqs mgag200.modeset=1

[   60.563598] BUG: unable to handle page fault for address:
ffffb80602983ff0 [   60.570478] #PF: supervisor write access in kernel mode
[   60.575701] #PF: error_code(0x0002) - not-present page
[   60.580833] PGD 813498067 P4D 813498067 PUD 813499067 PMD 80e0e0067 PTE 0
[   60.587619] Oops: 0002 [#1] PREEMPT SMP NOPTI
[   60.591979] CPU: 4 PID: 242 Comm: irq/34-xhci_hcd Tainted: G           O 
  T 5.4.42-gentoo #1 [   60.600585] Hardware name: Supermicro H8SCM/H8SCM,
BIOS 3.5b       03/18/2016 [   60.607723] RIP: 0010:__memcpy+0x12/0x20
[   60.611646] Code: c1 e2 20 48 09 c2 48 31 d3 e9 71 ff ff ff 90 90 90 90
90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07
<f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 [  
60.630401] RSP: 0018:ffffb806004a3c80 EFLAGS: 00010046
[   60.635628] RAX: ffffb80602983ff0 RBX: 0000000000000010 RCX:

000000000000000a [ 60.642759] RDX: 0000000000000000 RSI: ffff9d5f6659b000
RDI: ffffb80602983ff0 [ 60.649883] RBP: ffff9d5f62c38c00 R08:
0000000000000002 R09: 0000000000000000 [ 60.657017] R10: 0000000000000002
R11: 0000000000000001 R12: 0000000000000050 [ 60.664160] R13:
0000000000000000 R14: 0000000000079ff0 R15: ffff9d608c1d4908 [ 60.671293]
FS: 0000000000000000(0000) GS:ffff9d6096b00000(0000)
knlGS:0000000000000000 [ 60.679380] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033

[   60.685125] CR2: ffffb80602983ff0 CR3: 000000080f55c000 CR4:
00000000000406e0 [   60.692258] Call Trace:
[   60.694719]  retire_capture_urb+0x201/0x270 [snd_usb_audio]
[   60.700288]  snd_complete_urb+0x1b7/0x270 [snd_usb_audio]
[   60.705686]  __usb_hcd_giveback_urb+0x77/0xe0
[   60.710054]  xhci_giveback_urb_in_irq.isra.0+0x6d/0x100
[   60.715278]  xhci_td_cleanup+0xc4/0xe0
[   60.719032]  xhci_irq+0x825/0x1780
[   60.722438]  ? __schedule+0x2c3/0x650
[   60.726105]  ? irq_finalize_oneshot.part.0+0xd0/0xd0
[   60.731071]  irq_forced_thread_fn+0x25/0x70
[   60.735257]  irq_thread+0xea/0x170
[   60.738672]  ? wake_threads_waitq+0x30/0x30
[   60.742859]  kthread+0xf8/0x130
[   60.746005]  ? irq_thread_check_affinity+0x90/0x90
[   60.750805]  ? kthread_park+0x90/0x90
[   60.754473]  ret_from_fork+0x22/0x40
[   60.758053] Modules linked in: ebtable_filter ebtables bridge stp llc

netconsole wireguard ip6_udp_tunnel udp_tunnel xt_limit xt_comment xt_recent xt_multiport xt_MASQUERADE iptable_nat nf_nat nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6table_raw iptable_raw snd_seq_midi snd_seq_midi_event amd64_edac_mod kvm_amd kvm pcspkr irqbypass uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev snd_hda_codec_hdmi videobuf2_common snd_hda_intel joydev snd_intel_nhlt snd_hda_codec snd_usb_audio sp5100_tco snd_usbmidi_lib snd_rawmidi snd_hwdep e1000e snd_hda_core snd_pcm nfsd tcp_yeah tcp_vegas sch_fq_codel uas amdgpu crc32c_intel mgag200 drm_vram_helper gpu_sched ttm vhost_scsi target_core_mod configfs vhost_net tun tap vhost vhba(O) jc42
ipmi_si ipmi_devintf ipmi_msghandler fuse eeprom [ 60.828924] CR2:
ffffb80602983ff0

[   60.832245] ---[ end trace 1945ea8b50798a03 ]---
[   60.836862] RIP: 0010:__memcpy+0x12/0x20
[   60.840797] Code: c1 e2 20 48 09 c2 48 31 d3 e9 71 ff ff ff 90 90 90 90
90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07
<f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 [  
60.859553] RSP: 0018:ffffb806004a3c80 EFLAGS: 00010046
[   60.864778] RAX: ffffb80602983ff0 RBX: 0000000000000010 RCX:

000000000000000a [ 60.871911] RDX: 0000000000000000 RSI: ffff9d5f6659b000
RDI: ffffb80602983ff0 [ 60.879036] RBP: ffff9d5f62c38c00 R08:
0000000000000002 R09: 0000000000000000 [ 60.886168] R10: 0000000000000002
R11: 0000000000000001 R12: 0000000000000050 [ 60.893301] R13:
0000000000000000 R14: 0000000000079ff0 R15: ffff9d608c1d4908 [ 60.900453]
FS: 0000000000000000(0000) GS:ffff9d6096b00000(0000)
knlGS:0000000000000000 [ 60.908538] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033

[   60.914276] CR2: ffffb80602983ff0 CR3: 000000080f55c000 CR4:

00000000000406e0 [ 60.921411] Kernel panic - not syncing: Fatal exception
in interrupt [ 60.927783] Kernel Offset: 0x21000000 from
0xffffffff81000000 (relocation range:
0xffffffff80000000-0xffffffffbfffffff) [ 60.938554] ---[ end Kernel panic
- not syncing: Fatal exception in interrupt ]---

Quoted 11 lines · On zaterdag 23 mei 2020 19:53:49 CEST Alexander Tsoy wrote:

В Вс, 10/05/2020 в 20:29 +0200, Erwin Burema пишет:

Quoted 10 lines

For USB sound devices using implicit feedback the endpoint used for this feedback should be able to be opened twice, once for required feedback and second time for audio data. This way these devices can be put in duplex audio mode. Since this only works if the settings of the endpoint don't change a check is included for this.

This fixes bug 207023 ("MOTU M2 regression on duplex audio") and should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex")

Quoted 6 lines

Quoted 2 lines

Signed-off-by Erwin Burema <[email protected]>

---

This patch seems to cause kernel panic on my system. This happens during boot when gdm (with pulseaudio) is starting up.

That's interesting, not running gnome (and thus also not running gdm, currently KDE with SDDM) here so would need to take some time troubleshooting. Suspect I missed something in the check if both input and output are similarly configured.

Will see if I can reproduce it and where exactly it goes wrong, in the meantime would it be possible to test if 5.6 or later show the same issue since I intially developed the patch against that release?

On Sat, 23 May 2020 20:09:31 +0200,

Quoted 18 lines · Erwin Burema

Quoted 11 lines · On zaterdag 23 mei 2020 19:53:49 CEST Alexander Tsoy wrote:

В Вс, 10/05/2020 в 20:29 +0200, Erwin Burema пишет:

Quoted 10 lines

For USB sound devices using implicit feedback the endpoint used for this feedback should be able to be opened twice, once for required feedback and second time for audio data. This way these devices can be put in duplex audio mode. Since this only works if the settings of the endpoint don't change a check is included for this.

This fixes bug 207023 ("MOTU M2 regression on duplex audio") and should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex")

Quoted 5 lines

Quoted 2 lines

Signed-off-by Erwin Burema <[email protected]>

---

This patch seems to cause kernel panic on my system. This happens during boot when gdm (with pulseaudio) is starting up.

Quoted 8 lines

That's interesting, not running gnome (and thus also not running gdm, currently KDE with SDDM) here so would need to take some time troubleshooting. Suspect I missed something in the check if both input and output are similarly configured.

Will see if I can reproduce it and where exactly it goes wrong, in the meantime would it be possible to test if 5.6 or later show the same issue since I intially developed the patch against that release?

Judging from the point triggering the bug (memset()), this can be a leftover URB handling that is performed even after the capture stream is closed. If so, the procedure would be:
- start capture
- start playback
- stop capture while keeping playback running

If my guess is correct, can the patch below work around the issue?

thanks,

Takashi

---

sound/usb/pcm.c +1 -0

@@ -1782,6 +1782,7 @@ static int snd_usb_substream_capture_trigger(struct
 snd_pcm_substream *substream return 0;
 	case SNDRV_PCM_TRIGGER_STOP:
 		stop_endpoints(subs);
+		subs->data_endpoint->retire_data_urb = NULL;
 		subs->running = 0;
 		return 0;
 	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:

Quoted 30 lines · On zondag 24 mei 2020 10:37:34 CEST Takashi Iwai wrote:

On Sat, 23 May 2020 20:09:31 +0200,

Quoted 18 lines · Erwin Burema

Quoted 11 lines · On zaterdag 23 mei 2020 19:53:49 CEST Alexander Tsoy wrote:

В Вс, 10/05/2020 в 20:29 +0200, Erwin Burema пишет:

Quoted 10 lines

For USB sound devices using implicit feedback the endpoint used for this feedback should be able to be opened twice, once for required feedback and second time for audio data. This way these devices can be put in duplex audio mode. Since this only works if the settings of the endpoint don't change a check is included for this.

This fixes bug 207023 ("MOTU M2 regression on duplex audio") and should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex")

Quoted 5 lines

Quoted 2 lines

Signed-off-by Erwin Burema <[email protected]>

---

This patch seems to cause kernel panic on my system. This happens during boot when gdm (with pulseaudio) is starting up.

Quoted 8 lines

That's interesting, not running gnome (and thus also not running gdm, currently KDE with SDDM) here so would need to take some time troubleshooting. Suspect I missed something in the check if both input and output are similarly configured.

Will see if I can reproduce it and where exactly it goes wrong, in the meantime would it be possible to test if 5.6 or later show the same issue since I intially developed the patch against that release?

Quoted 9 lines

Judging from the point triggering the bug (memset()), this can be a leftover URB handling that is performed even after the capture stream is closed. If so, the procedure would be:
- start capture
- start playback
- stop capture while keeping playback running

If my guess is correct, can the patch below work around the issue?

Have spend a large part of my free time trying to replicate it without any luck, might be due to tryin it in a VM with USB passtrough (but wanted to be able to quickly itterate and easier to get debug info), so haven't been able to try out the patch.

Next step is to see if I can replicate it on my HW, if that doesn't work it might be time to rethink this whole initial patch and might need to do something at substream level instead of endpoint level.

Regards,

Erwin Burema

Quoted 16 lines

thanks,

Takashi

---

sound/usb/pcm.c +1 -0

@@ -1782,6 +1782,7 @@ static int snd_usb_substream_capture_trigger(struct
 snd_pcm_substream *substream return 0;
 	case SNDRV_PCM_TRIGGER_STOP:
 		stop_endpoints(subs);
+		subs->data_endpoint->retire_data_urb = NULL;
 		subs->running = 0;
 		return 0;
 	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:

....

Let's see whether Alexander can test the patch.

Quoted 32 lines · Erwin Burema

Quoted 16 lines · On zaterdag 23 mei 2020 19:53:49 CEST Alexander Tsoy wrote:

В Вс, 10/05/2020 в 20:29 +0200, Erwin Burema пишет:

Quoted 15 lines

For USB sound devices using implicit feedback the endpoint used for
this feedback should be able to be opened twice, once for required
feedback and second time for audio data. This way these devices can
be put in duplex audio mode. Since this only works if the settings of
the endpoint don't change a check is included for this.

This fixes bug 207023 ("MOTU M2 regression on duplex audio") and
should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex")

Quoted 6 lines

Quoted 2 lines

Signed-off-by Erwin Burema <[email protected]>

---

This patch seems to cause kernel panic on my system. This happens during boot when gdm (with pulseaudio) is starting up.

That's interesting, not running gnome (and thus also not running gdm,
currently KDE with SDDM) here so would need to take some time troubleshooting.
Suspect I missed something in the check if both input and output are similarly
configured.

Quoted 5 lines

Will see if I can reproduce it and where exactly it goes wrong, in the
meantime would it be possible to test if 5.6 or later show the same issue
since I intially developed the patch against that release?

Judging from the point triggering the bug (memset()), this can be a leftover URB handling that is performed even after the capture stream is closed. If so, the procedure would be:
- start capture
- start playback
- stop capture while keeping playback running

If my guess is correct, can the patch below work around the issue?

В Вс, 24/05/2020 в 10:37 +0200, Takashi Iwai пишет:

Quoted 47 lines

Quoted 32 lines · Erwin Burema

Quoted 16 lines · On zaterdag 23 mei 2020 19:53:49 CEST Alexander Tsoy wrote:

В Вс, 10/05/2020 в 20:29 +0200, Erwin Burema пишет:

Quoted 15 lines

For USB sound devices using implicit feedback the endpoint used for
this feedback should be able to be opened twice, once for required
feedback and second time for audio data. This way these devices can
be put in duplex audio mode. Since this only works if the settings of
the endpoint don't change a check is included for this.

This fixes bug 207023 ("MOTU M2 regression on duplex audio") and
should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex")

Quoted 6 lines

Quoted 2 lines

Signed-off-by Erwin Burema <[email protected]>

---

This patch seems to cause kernel panic on my system. This happens during boot when gdm (with pulseaudio) is starting up.

That's interesting, not running gnome (and thus also not running gdm,
currently KDE with SDDM) here so would need to take some time troubleshooting.
Suspect I missed something in the check if both input and output are similarly
configured.

Quoted 5 lines

Will see if I can reproduce it and where exactly it goes wrong, in the
meantime would it be possible to test if 5.6 or later show the same issue
since I intially developed the patch against that release?

Judging from the point triggering the bug (memset()), this can be a leftover URB handling that is performed even after the capture stream is closed. If so, the procedure would be:
- start capture
- start playback
- stop capture while keeping playback running

Quoted 1 line

If my guess is correct, can the patch below work around the issue?

Unfortunately, I can no longer reproduce kernel panic, so can't really test this patch. That's interesting, because it was 100% reproducible on my hw a week ago.