[PATCH] Add duplex sound support for USB devices using implicit feedback

[Alexander Tsoy]

В Вс, 24/05/2020 в 10:37 +0200, Takashi Iwai пишет:
> On Sat, 23 May 2020 20:09:31 +0200,
> Erwin Burema wrote:
> > On zaterdag 23 mei 2020 19:53:49 CEST Alexander Tsoy wrote:
> > > В Вс, 10/05/2020 в 20:29 +0200, Erwin Burema пишет:
> > > > 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 <e.burema at gmail.com>
> > > > ---
> > > 
> > > 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?
> 
> 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?

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.