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

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

Re: Round-trip latency of USB Audio is not stable

Postby xmosfan » Fri Feb 23, 2018 12:51 am

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
Respected Member
Posts: 275
Joined: Fri Mar 12, 2010 6:03 pm

Postby larry » Wed Jun 27, 2018 1:17 pm

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.
Posts: 12
Joined: Tue Dec 13, 2016 9:45 am

Postby xmosfan » Thu Jun 28, 2018 12:59 am

Thanks larry! My project has already finished, but I will try your suggestion next time.

Who is online

Users browsing this forum: cl-b and 31 guests