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

[Takashi Iwai <tiwai@suse.de>]

On Mon, 01 Jun 2020 18:37:38 +0200,
Alexander Tsoy wrote:
> 
> В Вс, 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@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.

It's a pity, but interesting.  If so, it might be different from what
I've though in the above, and we might need a different fix...

Let me know if you can trigger the bug more or less reliably.


thanks,

Takashi