[PATCH] ALSA: usb-audio: work around streaming quirk for MacroSilicon MS2109

[PATCH] ALSA: usb-audio: work around streaming quirk for MacroSilicon MS2109

[Hector Martin]

Further investigation of the L-R swap problem on the MS2109 reveals that
the problem isn't that the channels are swapped, but rather that they
are swapped and also out of phase by one sample. In other words, the
issue is actually that the very first frame that comes from the hardware
is a half-frame containing only the right channel, and after that
everything becomes offset.

So introduce a new quirk field to drop the very first 2 bytes that come
in after the format is configured and a capture stream starts. This puts
the channels in phase and in the correct order.

Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 sound/usb/card.h   | 1 +
 sound/usb/pcm.c    | 6 ++++++
 sound/usb/quirks.c | 3 +++
 sound/usb/stream.c | 1 +
 4 files changed, 11 insertions(+)

diff --git a/sound/usb/card.h b/sound/usb/card.h
index de43267b9c8a..5351d7183b1b 100644
--- a/sound/usb/card.h
+++ b/sound/usb/card.h
@@ -137,6 +137,7 @@ struct snd_usb_substream {
 	unsigned int tx_length_quirk:1;	/* add length specifier to transfers */
 	unsigned int fmt_type;		/* USB audio format type (1-3) */
 	unsigned int pkt_offset_adj;	/* Bytes to drop from beginning of packets (for non-compliant devices) */
+	unsigned int stream_offset_adj;	/* Bytes to drop from beginning of stream (for non-compliant devices) */
 
 	unsigned int running: 1;	/* running status */
 
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index 415bfec49a01..5600751803cf 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -1420,6 +1420,12 @@ static void retire_capture_urb(struct snd_usb_substream *subs,
 			// continue;
 		}
 		bytes = urb->iso_frame_desc[i].actual_length;
+		if (subs->stream_offset_adj > 0) {
+			unsigned int adj = min(subs->stream_offset_adj, bytes);
+			cp += adj;
+			bytes -= adj;
+			subs->stream_offset_adj -= adj;
+		}
 		frames = bytes / stride;
 		if (!subs->txfr_quirk)
 			bytes = frames * stride;
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index c551141f337e..abf99b814a0f 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1495,6 +1495,9 @@ void snd_usb_set_format_quirk(struct snd_usb_substream *subs,
 	case USB_ID(0x2b73, 0x000a): /* Pioneer DJ DJM-900NXS2 */
 		pioneer_djm_set_format_quirk(subs);
 		break;
+	case USB_ID(0x534d, 0x2109): /* MacroSilicon MS2109 */
+		subs->stream_offset_adj = 2;
+		break;
 	}
 }
 
diff --git a/sound/usb/stream.c b/sound/usb/stream.c
index 4d1e6579e54d..ca76ba5b5c0b 100644
--- a/sound/usb/stream.c
+++ b/sound/usb/stream.c
@@ -94,6 +94,7 @@ static void snd_usb_init_substream(struct snd_usb_stream *as,
 	subs->tx_length_quirk = as->chip->tx_length_quirk;
 	subs->speed = snd_usb_get_speed(subs->dev);
 	subs->pkt_offset_adj = 0;
+	subs->stream_offset_adj = 0;
 
 	snd_usb_set_pcm_ops(as->pcm, stream);
 
-- 
2.27.0

Re: [PATCH] ALSA: usb-audio: work around streaming quirk for MacroSilicon MS2109

[Takashi Iwai]

On Mon, 10 Aug 2020 10:24:00 +0200,
Hector Martin wrote:
> 
> Further investigation of the L-R swap problem on the MS2109 reveals that
> the problem isn't that the channels are swapped, but rather that they
> are swapped and also out of phase by one sample. In other words, the
> issue is actually that the very first frame that comes from the hardware
> is a half-frame containing only the right channel, and after that
> everything becomes offset.
> 
> So introduce a new quirk field to drop the very first 2 bytes that come
> in after the format is configured and a capture stream starts. This puts
> the channels in phase and in the correct order.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Hector Martin <marcan@marcan.st>

Hm, that's fairly weird behavior, but the workaround looks simple
enough, so now I applied as is.


thanks,

Takashi

Re: [PATCH] ALSA: usb-audio: work around streaming quirk for MacroSilicon MS2109

[Hector Martin 'marcan']

On 10/08/2020 19.59, Takashi Iwai wrote:
> Hm, that's fairly weird behavior, but the workaround looks simple
> enough, so now I applied as is.

Chinese $10 capture card quality silicon... :-)

FWIW I tried stopping and starting the stream repeatedly and the 
workaround seems to be reliable. I also checked the packets with usbmon 
to confirm that there is no weirdness in the driver, it's really how the 
data comes in from the very first isoc packet sent by the hardware.

-- 
Hector Martin "marcan" (marcan@marcan.st)
Public Key: https://mrcn.st/pub