Round-trip latency of USB Audio is not stable Topic is solved

If you have a simple question and just want an answer.
xmosfan
Member
Posts: 13
Joined: Tue Dec 13, 2016 9:45 am

Post by xmosfan »

Ross wrote: The Thesycon driver implementation ignores the feedback pipe and always uses the input stream when available. You should see it use it for and output only device.
I have noticed that Thesycon driver works as Implicit Feedback on Windows. In case of MacOS, InBox driver works as Explicit Feedback. Maybe, this is not related to unstable latency of XMOS.
By the way, is there any solution to fix the XMOS latency? ASIO driver needs stable latency in every connection. DAW adjusts the position of recorded wave by the Terminal Latency value - response against TE_LATENCY_CONTROL.
(".bmControls" value in .Audio_ClassControlInterface must be '0x01'. So, Windows issues TE_LATENCY_CONTROL message and requests it's value.)


View Solution
User avatar
larry
Respected Member
Posts: 275
Joined: Fri Mar 12, 2010 6:03 pm

Post by larry »

Variability across start and stop occurs in the input path, ie device to host.

When streaming stops, buffer of the input path (called aud_to_host_fifo in the code) overflows. There is a mechanism in there to reset the buffer to half full and stay like that until streaming resumes. It does that on by discarding packets in a loop (search for "Keep throwing away packets") until buffer fullness in bytes exceeds a threshold of half the buffer size (BUFF_SIZE_IN).

I suspect that should there be packets of different sizes in the buffer, you could end up with one more or one less packet. To illustrate that, consider 6+6+6+7 which exceeds a threshold of 24 and 6+6+6+6 which doesn't. To test this you could save details of each reset run of the "throwing away" loop, print them and compare.

A solution would then be a reset procedure for the input buffer that forces a certain number of samples regardless of rate matching. For example always 6666, never allowing 6667. This almost goes against USB specification. In general, I wasn't aware of any requirements on latency through device in USB and USB audio specifications, which leaves it up to implementations how they behave during underflow and overflow. It also means that a change is unlikely to affect USB compliance.
xmosfan
Member
Posts: 13
Joined: Tue Dec 13, 2016 9:45 am

Post by xmosfan »

Thanks larry! My project has already finished, but I will try your suggestion next time.
shaw
Active Member
Posts: 43
Joined: Fri Mar 25, 2011 12:36 am

Post by shaw »

We have encountered this same issue with inconsistent round-trip latency measurements, as described above (same setup as original post) . I see that this issue was marked as solved, but I wasn't sure of the actual solution. Any guidance on how this issue was solved, would be appreciated. Thanks
xmosfan
Member
Posts: 13
Joined: Tue Dec 13, 2016 9:45 am

Post by xmosfan »

shaw wrote: Fri Dec 13, 2019 4:36 pm We have encountered this same issue with inconsistent round-trip latency measurements, as described above (same setup as original post) . I see that this issue was marked as solved, but I wasn't sure of the actual solution. Any guidance on how this issue was solved, would be appreciated. Thanks
My project has finished several years ago. I could not make the stable latency at that time.
In this forum, I could get hint about clear input buffer. I wanted to test it.
But, I had moved to another project team already. Unfortunately, that team doesn't treat XMOS...
I hope that you solve this issue completely. Good luck.
Post Reply