Hello,
I've found an interesting issue with an SSL2+ audio interface -- it plays and records fine (and, for the money, the sound quality is excellent!), but recording slowly but surely drifts over time. For example, if I record a click track in Audacity (or Ardour), play it through the interface and record it, and then line up the start of the recorded click track with the original, the two tracks will be around 5ms out of alignment after 30s. Interestingly, this problem does not happen with OpenBSD, where the two tracks line up precisely.
My guess is that the problem is to do with implicit feedback in endpoints. I wondered if the problem was the same as with the MOTU M4, but enabling that quirk for the SSL2+ introduced some crackle, but didn't change the drift.
I'm attaching a) the alsa-info file b) output from OpenBSD's kernel with debugging in the USB audio driver turned on in case that gives some clues as to what the two OS's and drivers might be doing differently. If anyone has any suggestions for how this problem might be addressed, I would be very grateful!
Laurie
On Sun, 07 Jun 2020 15:39:59 +0200, Laurence Tratt wrote:
Hello,
I've found an interesting issue with an SSL2+ audio interface -- it plays and records fine (and, for the money, the sound quality is excellent!), but recording slowly but surely drifts over time. For example, if I record a click track in Audacity (or Ardour), play it through the interface and record it, and then line up the start of the recorded click track with the original, the two tracks will be around 5ms out of alignment after 30s. Interestingly, this problem does not happen with OpenBSD, where the two tracks line up precisely.
My guess is that the problem is to do with implicit feedback in endpoints. I wondered if the problem was the same as with the MOTU M4, but enabling that quirk for the SSL2+ introduced some crackle, but didn't change the drift.
I'm attaching a) the alsa-info file b) output from OpenBSD's kernel with debugging in the USB audio driver turned on in case that gives some clues as to what the two OS's and drivers might be doing differently. If anyone has any suggestions for how this problem might be addressed, I would be very grateful!
The recent change in USB-audio might help for a case like yours. Try my sound git tree (for-linus branch) or Linus' tree. The former should be pullable onto 5.7 kernel cleanly.
thanks,
Takashi
On 08.06.20 09:19, Takashi Iwai wrote:
On Sun, 07 Jun 2020 15:39:59 +0200, Laurence Tratt wrote:
Hello,
I've found an interesting issue with an SSL2+ audio interface -- it plays and records fine (and, for the money, the sound quality is excellent!), but recording slowly but surely drifts over time. For example, if I record a click track in Audacity (or Ardour), play it through the interface and record it, and then line up the start of the recorded click track with the original, the two tracks will be around 5ms out of alignment after 30s. Interestingly, this problem does not happen with OpenBSD, where the two tracks line up precisely.
The recent change in USB-audio might help for a case like yours. Try my sound git tree (for-linus branch) or Linus' tree. The former should be pullable onto 5.7 kernel cleanly.
Since I recently had clock drift issues with Audient devices, I'm intrigued by this. @Takashi Can you quickly elaborate, what you think, Laurance's issue might be and what has changed in that tree that might help him fix it? Is there some general issue with the current (stable) sound/usb implementation?
Thanks!
Thomas
On Mon, 08 Jun 2020 10:32:24 +0200, Thomas Ebeling wrote:
On 08.06.20 09:19, Takashi Iwai wrote:
On Sun, 07 Jun 2020 15:39:59 +0200, Laurence Tratt wrote:
Hello,
I've found an interesting issue with an SSL2+ audio interface -- it plays and records fine (and, for the money, the sound quality is excellent!), but recording slowly but surely drifts over time. For example, if I record a click track in Audacity (or Ardour), play it through the interface and record it, and then line up the start of the recorded click track with the original, the two tracks will be around 5ms out of alignment after 30s. Interestingly, this problem does not happen with OpenBSD, where the two tracks line up precisely.
The recent change in USB-audio might help for a case like yours. Try my sound git tree (for-linus branch) or Linus' tree. The former should be pullable onto 5.7 kernel cleanly.
Since I recently had clock drift issues with Audient devices, I'm intrigued by this. @Takashi Can you quickly elaborate, what you think, Laurance's issue might be and what has changed in that tree that might help him fix it? Is there some general issue with the current (stable) sound/usb implementation?
The frame size calculation in USB-audio driver wasn't accurate enough because of the computation in Q16.16 format. It works OK for async mode, but for others, it can accumulate rounding errors. The recent change corrected it for a more precise way.
Takashi
В Пн, 08/06/2020 в 15:35 +0200, Takashi Iwai пишет:
On Mon, 08 Jun 2020 10:32:24 +0200, Thomas Ebeling wrote:
On 08.06.20 09:19, Takashi Iwai wrote:
On Sun, 07 Jun 2020 15:39:59 +0200, Laurence Tratt wrote:
Hello,
I've found an interesting issue with an SSL2+ audio interface -- it plays and records fine (and, for the money, the sound quality is excellent!), but recording slowly but surely drifts over time. For example, if I record a click track in Audacity (or Ardour), play it through the interface and record it, and then line up the start of the recorded click track with the original, the two tracks will be around 5ms out of alignment after 30s. Interestingly, this problem does not happen with OpenBSD, where the two tracks line up precisely.
The recent change in USB-audio might help for a case like yours. Try my sound git tree (for-linus branch) or Linus' tree. The former should be pullable onto 5.7 kernel cleanly.
Since I recently had clock drift issues with Audient devices, I'm intrigued by this. @Takashi Can you quickly elaborate, what you think, Laurance's issue might be and what has changed in that tree that might help him fix it? Is there some general issue with the current (stable) sound/usb implementation?
The frame size calculation in USB-audio driver wasn't accurate enough because of the computation in Q16.16 format. It works OK for async mode, but for others, it can accumulate rounding errors. The recent change corrected it for a more precise way.
I believe that SSL and Audient devices operates in async mode. Would be nice to see "lsusb -v" output for them.
On Mon, Jun 08, 2020 at 05:43:05PM +0300, Alexander Tsoy wrote:
Hello Alexander,
The frame size calculation in USB-audio driver wasn't accurate enough because of the computation in Q16.16 format. It works OK for async mode, but for others, it can accumulate rounding errors. The recent change corrected it for a more precise way.
I believe that SSL and Audient devices operates in async mode. Would be nice to see "lsusb -v" output for them.
Please find attached the "lsusb -v" output.
Laurie
В Ср, 10/06/2020 в 08:44 +0100, Laurence Tratt пишет:
On Mon, Jun 08, 2020 at 05:43:05PM +0300, Alexander Tsoy wrote:
Hello Alexander,
The frame size calculation in USB-audio driver wasn't accurate enough because of the computation in Q16.16 format. It works OK for async mode, but for others, it can accumulate rounding errors. The recent change corrected it for a more precise way.
I believe that SSL and Audient devices operates in async mode. Would be nice to see "lsusb -v" output for them.
Please find attached the "lsusb -v" output.
Thanks! So SSL 2+ is indeed currently needs implicit feedback quirk. The question is why it didn't help in your case.
On Wed, Jun 10, 2020 at 04:49:14PM +0300, Alexander Tsoy wrote:
Hello Alexander,
Thanks! So SSL 2+ is indeed currently needs implicit feedback quirk. The question is why it didn't help in your case.
It didn't work because I was an idiot and used the wrong manufacturer ID. When I fixed that typo, the drift disappeared. Patch attached!
[It's reasonable to assume that this will also work for the SSL2, but I don't know its ID: it might use the same ID as the SSL2+ or perhaps its 0x0001. Unfortunately I suspect we'll have to wait until one is observed in the wild to know.]
Laurie
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 8a05dcb134..abf726c49f 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -367,6 +367,7 @@ static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, ifnum = 0; goto add_sync_ep_from_ifnum; case USB_ID(0x07fd, 0x0008): /* MOTU M Series */ + case USB_ID(0x31e9, 0x0002): /* Solid State Logic SSL2+ */ ep = 0x81; ifnum = 2; goto add_sync_ep_from_ifnum;
On Wed, 10 Jun 2020 18:29:12 +0200, Laurence Tratt wrote:
On Wed, Jun 10, 2020 at 04:49:14PM +0300, Alexander Tsoy wrote:
Hello Alexander,
Thanks! So SSL 2+ is indeed currently needs implicit feedback quirk. The question is why it didn't help in your case.
It didn't work because I was an idiot and used the wrong manufacturer ID. When I fixed that typo, the drift disappeared. Patch attached!
Great, care to submit the patch in a proper format?
[It's reasonable to assume that this will also work for the SSL2, but I don't know its ID: it might use the same ID as the SSL2+ or perhaps its 0x0001. Unfortunately I suspect we'll have to wait until one is observed in the wild to know.]
Yes, the addition can be done easily at any time, so let's take the known working one at first.
thanks,
Takashi
Laurie
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 8a05dcb134..abf726c49f 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -367,6 +367,7 @@ static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, ifnum = 0; goto add_sync_ep_from_ifnum; case USB_ID(0x07fd, 0x0008): /* MOTU M Series */
- case USB_ID(0x31e9, 0x0002): /* Solid State Logic SSL2+ */ ep = 0x81; ifnum = 2; goto add_sync_ep_from_ifnum;
participants (4)
-
Alexander Tsoy -
Laurence Tratt -
Takashi Iwai -
Thomas Ebeling