diff mbox series

ALSA: usb-audio: Add quirk for Tascam Model 12

Message ID 20221128122353.763696-1-john@metanate.com (mailing list archive)
State Superseded
Headers show
Series ALSA: usb-audio: Add quirk for Tascam Model 12 | expand

Commit Message

John Keeping Nov. 28, 2022, 12:23 p.m. UTC
Tascam's Model 12 is a mixer which can also operate as a USB audio
interface.  The audio interface uses explicit feedback but it seems that
it does not correctly handle missing isochronous frames.

When injecting an xrun (or doing anything else that pauses the playback
stream) the feedback rate climbs (for example, at 44,100Hz nominal, I
see a stable rate around 44,099 but xrun injection sees this peak at
around 44,135 in most cases) and glitches are heard in the audio stream
for several seconds - this is significantly worse than the single glitch
expected for an underrun.

While the stream does normally recover and the feedback rate returns to
a stable value, I have seen some occurrences where this does not happen
and the rate continues to increase while no audio is heard from the
output.  I have not found a solid reproduction for this.

This misbehaviour can be avoided by totally resetting the stream state
by switching the interface to alt 0 and back before restarting the
playback stream.

Add a new quirk flag which forces the endpoint and interface to be
reconfigured whenever the stream is stopped, and use this for the Tascam
Model 12.

Signed-off-by: John Keeping <john@metanate.com>
---
 sound/usb/endpoint.c | 7 +++++++
 sound/usb/quirks.c   | 2 ++
 sound/usb/usbaudio.h | 4 ++++
 3 files changed, 13 insertions(+)

Comments

Takashi Iwai Nov. 28, 2022, 1:51 p.m. UTC | #1
On Mon, 28 Nov 2022 13:23:52 +0100,
John Keeping wrote:
> 
> Tascam's Model 12 is a mixer which can also operate as a USB audio
> interface.  The audio interface uses explicit feedback but it seems that
> it does not correctly handle missing isochronous frames.
> 
> When injecting an xrun (or doing anything else that pauses the playback
> stream) the feedback rate climbs (for example, at 44,100Hz nominal, I
> see a stable rate around 44,099 but xrun injection sees this peak at
> around 44,135 in most cases) and glitches are heard in the audio stream
> for several seconds - this is significantly worse than the single glitch
> expected for an underrun.
> 
> While the stream does normally recover and the feedback rate returns to
> a stable value, I have seen some occurrences where this does not happen
> and the rate continues to increase while no audio is heard from the
> output.  I have not found a solid reproduction for this.
> 
> This misbehaviour can be avoided by totally resetting the stream state
> by switching the interface to alt 0 and back before restarting the
> playback stream.
> 
> Add a new quirk flag which forces the endpoint and interface to be
> reconfigured whenever the stream is stopped, and use this for the Tascam
> Model 12.
> 
> Signed-off-by: John Keeping <john@metanate.com>

Thanks for the patch, it's an interesting case.
About the code change:

> --- a/sound/usb/endpoint.c
> +++ b/sound/usb/endpoint.c
> @@ -1673,6 +1673,13 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep, bool keep_pending)
>  		stop_urbs(ep, false, keep_pending);
>  		if (ep->clock_ref)
>  			atomic_dec(&ep->clock_ref->locked);
> +
> +		if (ep->chip->quirk_flags & QUIRK_FLAG_FORCE_IFACE_RESET &&
> +		    usb_pipeout(ep->pipe)) {
> +			ep->need_setup = true;
> +			if (ep->iface_ref)
> +				ep->iface_ref->need_setup = true;
> +		}

Is this the forced reset always safe?  Imagine that you have
individual playback and capture streams, and what if only one of them
gets stopped and restarted while another keeps running?


thanks,

Takashi
John Keeping Nov. 28, 2022, 7:20 p.m. UTC | #2
On Mon, Nov 28, 2022 at 02:51:15PM +0100, Takashi Iwai wrote:
> On Mon, 28 Nov 2022 13:23:52 +0100,
> John Keeping wrote:
> > 
> > Tascam's Model 12 is a mixer which can also operate as a USB audio
> > interface.  The audio interface uses explicit feedback but it seems that
> > it does not correctly handle missing isochronous frames.
> > 
> > When injecting an xrun (or doing anything else that pauses the playback
> > stream) the feedback rate climbs (for example, at 44,100Hz nominal, I
> > see a stable rate around 44,099 but xrun injection sees this peak at
> > around 44,135 in most cases) and glitches are heard in the audio stream
> > for several seconds - this is significantly worse than the single glitch
> > expected for an underrun.
> > 
> > While the stream does normally recover and the feedback rate returns to
> > a stable value, I have seen some occurrences where this does not happen
> > and the rate continues to increase while no audio is heard from the
> > output.  I have not found a solid reproduction for this.
> > 
> > This misbehaviour can be avoided by totally resetting the stream state
> > by switching the interface to alt 0 and back before restarting the
> > playback stream.
> > 
> > Add a new quirk flag which forces the endpoint and interface to be
> > reconfigured whenever the stream is stopped, and use this for the Tascam
> > Model 12.
> > 
> > Signed-off-by: John Keeping <john@metanate.com>
> 
> Thanks for the patch, it's an interesting case.
> About the code change:
> 
> > --- a/sound/usb/endpoint.c
> > +++ b/sound/usb/endpoint.c
> > @@ -1673,6 +1673,13 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep, bool keep_pending)
> >  		stop_urbs(ep, false, keep_pending);
> >  		if (ep->clock_ref)
> >  			atomic_dec(&ep->clock_ref->locked);
> > +
> > +		if (ep->chip->quirk_flags & QUIRK_FLAG_FORCE_IFACE_RESET &&
> > +		    usb_pipeout(ep->pipe)) {
> > +			ep->need_setup = true;

It seems I missed this when forward porting the patch from 5.15 - this
should be setting ep->need_prepare and will change in v2.

> > +			if (ep->iface_ref)
> > +				ep->iface_ref->need_setup = true;
> > +		}
> 
> Is this the forced reset always safe?  Imagine that you have
> individual playback and capture streams, and what if only one of them
> gets stopped and restarted while another keeps running?

I /think/ this is okay because the interfaces for capture & playback are
separate (although the clock is shared).

There are two endpoints on the playback interface - the playback data
and explicit feedback endpoints - but these are always stopped and
started at the same time so I can't see any problem here.  (Only the
data endpoint will trigger the reset request here due to the
usb_pipeout() check.)
Takashi Iwai Nov. 29, 2022, 7:13 a.m. UTC | #3
On Mon, 28 Nov 2022 20:20:05 +0100,
John Keeping wrote:
> 
> On Mon, Nov 28, 2022 at 02:51:15PM +0100, Takashi Iwai wrote:
> > On Mon, 28 Nov 2022 13:23:52 +0100,
> > John Keeping wrote:
> > > 
> > > Tascam's Model 12 is a mixer which can also operate as a USB audio
> > > interface.  The audio interface uses explicit feedback but it seems that
> > > it does not correctly handle missing isochronous frames.
> > > 
> > > When injecting an xrun (or doing anything else that pauses the playback
> > > stream) the feedback rate climbs (for example, at 44,100Hz nominal, I
> > > see a stable rate around 44,099 but xrun injection sees this peak at
> > > around 44,135 in most cases) and glitches are heard in the audio stream
> > > for several seconds - this is significantly worse than the single glitch
> > > expected for an underrun.
> > > 
> > > While the stream does normally recover and the feedback rate returns to
> > > a stable value, I have seen some occurrences where this does not happen
> > > and the rate continues to increase while no audio is heard from the
> > > output.  I have not found a solid reproduction for this.
> > > 
> > > This misbehaviour can be avoided by totally resetting the stream state
> > > by switching the interface to alt 0 and back before restarting the
> > > playback stream.
> > > 
> > > Add a new quirk flag which forces the endpoint and interface to be
> > > reconfigured whenever the stream is stopped, and use this for the Tascam
> > > Model 12.
> > > 
> > > Signed-off-by: John Keeping <john@metanate.com>
> > 
> > Thanks for the patch, it's an interesting case.
> > About the code change:
> > 
> > > --- a/sound/usb/endpoint.c
> > > +++ b/sound/usb/endpoint.c
> > > @@ -1673,6 +1673,13 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep, bool keep_pending)
> > >  		stop_urbs(ep, false, keep_pending);
> > >  		if (ep->clock_ref)
> > >  			atomic_dec(&ep->clock_ref->locked);
> > > +
> > > +		if (ep->chip->quirk_flags & QUIRK_FLAG_FORCE_IFACE_RESET &&
> > > +		    usb_pipeout(ep->pipe)) {
> > > +			ep->need_setup = true;
> 
> It seems I missed this when forward porting the patch from 5.15 - this
> should be setting ep->need_prepare and will change in v2.
> 
> > > +			if (ep->iface_ref)
> > > +				ep->iface_ref->need_setup = true;
> > > +		}
> > 
> > Is this the forced reset always safe?  Imagine that you have
> > individual playback and capture streams, and what if only one of them
> > gets stopped and restarted while another keeps running?
> 
> I /think/ this is okay because the interfaces for capture & playback are
> separate (although the clock is shared).
> 
> There are two endpoints on the playback interface - the playback data
> and explicit feedback endpoints - but these are always stopped and
> started at the same time so I can't see any problem here.  (Only the
> data endpoint will trigger the reset request here due to the
> usb_pipeout() check.) 

Ah OK, then it should be safe -- and it'd be worth to mention it in
the changelog, too (hint for the resubmission :)


Takashi
diff mbox series

Patch

diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
index 310cd6fb0038..ab248d554774 100644
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -1673,6 +1673,13 @@  void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep, bool keep_pending)
 		stop_urbs(ep, false, keep_pending);
 		if (ep->clock_ref)
 			atomic_dec(&ep->clock_ref->locked);
+
+		if (ep->chip->quirk_flags & QUIRK_FLAG_FORCE_IFACE_RESET &&
+		    usb_pipeout(ep->pipe)) {
+			ep->need_setup = true;
+			if (ep->iface_ref)
+				ep->iface_ref->need_setup = true;
+		}
 	}
 }
 
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 0f4dd3503a6a..58b37bfc885c 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2044,6 +2044,8 @@  static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 	DEVICE_FLG(0x0644, 0x804a, /* TEAC UD-301 */
 		   QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY |
 		   QUIRK_FLAG_IFACE_DELAY),
+	DEVICE_FLG(0x0644, 0x805f, /* TEAC Model 12 */
+		   QUIRK_FLAG_FORCE_IFACE_RESET),
 	DEVICE_FLG(0x06f8, 0xb000, /* Hercules DJ Console (Windows Edition) */
 		   QUIRK_FLAG_IGNORE_CTL_ERROR),
 	DEVICE_FLG(0x06f8, 0xd002, /* Hercules DJ Console (Macintosh Edition) */
diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
index e97141ef730a..2aba508a4831 100644
--- a/sound/usb/usbaudio.h
+++ b/sound/usb/usbaudio.h
@@ -172,6 +172,9 @@  extern bool snd_usb_skip_validation;
  *  Don't apply implicit feedback sync mode
  * QUIRK_FLAG_IFACE_SKIP_CLOSE
  *  Don't closed interface during setting sample rate
+ * QUIRK_FLAG_FORCE_IFACE_RESET
+ *  Force an interface reset whenever stopping & restarting a stream
+ *  (e.g. after xrun)
  */
 
 #define QUIRK_FLAG_GET_SAMPLE_RATE	(1U << 0)
@@ -194,5 +197,6 @@  extern bool snd_usb_skip_validation;
 #define QUIRK_FLAG_GENERIC_IMPLICIT_FB	(1U << 17)
 #define QUIRK_FLAG_SKIP_IMPLICIT_FB	(1U << 18)
 #define QUIRK_FLAG_IFACE_SKIP_CLOSE	(1U << 19)
+#define QUIRK_FLAG_FORCE_IFACE_RESET	(1U << 20)
 
 #endif /* __USBAUDIO_H */