You might be interested in this document, section 3.3:
All of your devices are isochronous (real time reserved bandwidth), but the “Synch Type” on one is adaptive (Devio CR-1), the others are asynchronous (ClearOne Convergence Huddle and Devio SCR-25). Note that this is specified by the device itself, although any driver would perhaps have to also change its own behavior depending on type, e.g., a driver not knowing the bit rate was going to change might have various errors.
An asychronous mode implies that if for any reason the data rate can’t be handled, then drops will occur. This could be considered an error condition, and although not fatal, I don’t think that temporary errors have any kind of defined behavior…it would be up to the software to decide things like “use 0” or “use last value” for amplitude of missing data.
An adaptive mode implies that bit rate can change to adapt to conditions. I don’t know if you’ve ever used video capture software, but this is a good illustration where the better/newer software can operate at a constant bit rate, or to instead operate at a constant quality level.
It isn’t clear for me which microphone/speaker combination was dropping bits, versus working cleanly in the sine wave patterns, but I’m going to guess adaptive or microphone/speaker combinations which were lower sample rates did not have the problem. There are just so many posts now it is hard to re-read all of them, but my impression is that the adaptive is working correctly, and the asynchronous units have issues as bit rate goes up. Is this correct? If so, then you have no choice but to either reduce the bit rate or increase the ability of the system to handle the higher bit rates. The former is easy, the latter may be problematic.
I will try to summarize the devices info and behaviour:
The Adaptive mode is present only on Devio CR-1 Speaker interface. The Devio CR-1 Microphone interface and all other Speaker/Microphone interfaces (Devio SCR-25, ClearOne) are Asynchronous.
There is no issue with the Speaker interfaces or Microphone/Speaker combination, even with the Asynchronous ones. All the Speaker interfaces works well.
The bits dropping issue is present on all the Microphone interfaces when recording audio; with the Devio CR-1 I can use sample rate 32000, so I can avoid bits dropping issue. With the Devio SCR-25 and ClearOne I have only 48000 sample rate available, so I can’t avoid the bits dropping issue. If I use the XHCI driver instead of the EHCI driver, I don’t have bits dropping issue with none of those devices.
I have another Asynchronous Microphone device with 48000 sample rate only, but this works well. It is a high-speed device (480 Mbit/s), while the other devices (Devio CR-1, Devio SCR-25, ClearOne) are full-speed (12 Mbit/s). So I can suppose that the TK1 EHCI driver presents dropping bits issue using Asynchronous mode and 48000 sample rate, but only with full-speed devices and not with high-speed devices.
Thank you, best regards.
This narrows it down to isochronous mode of EHCI driver dropping bits on this particular hardware.
Restating this for comments:
“… If I use the XHCI driver instead of the EHCI driver, I don’t have bits dropping issue with none of those devices. …”
A comment about the layout of USB controllers might be useful here. Usually (always?) a USB2 controller has backwards compatibility to provide for USB1.1 and USB1.0 standards. USB3 can have its own controller without a legacy mode, and then reroute data to a separate legacy controller (a case where even USB2 is legacy). However, for this case, we are only considering USB2, and XHCI versus EHCI.
I believe NVIDIA provides the XHCI driver (correct me if I’m wrong on that, it might just be the USB3 driver NVIDIA provides, but either way the EHCI on Tegra hardware is what is in question), and that any reversion to a legacy mode which uses EHCI would result in using a driver not provided by NVIDIA, but on the NVIDIA legacy hardware. If EHCI is using the legacy hardware incorrectly, or without optimizing, then this could easily cause bit drops in isochronous mode.
Would someone from NVIDIA be able to comment on when the EHCI driver loads (instead of XHCI), and perhaps on whether there is any ability to improve on the EHCI driver in isochronous mode to avoid dropping bits? Both microphones together will use “4800082 == 768000” bits/sec (plus overhead), which is easily within the USB1.1 bandwidth. Perhaps nothing more than a tweak to the IRQ priority would make this work since only the USB1.1 mode on this hardware is dropping bits and even a slight increase in priority might give the driver time to process those bits.
For TK1, the latest release is https://developer.nvidia.com/linux-tegra-r217
As of now there is no plan to have new release. Please check ehci driver in kernel source:
And also compliance tuning guide:
Hi linuxdev, we really appreciate your active helps, from TK1 to Xavier/Nano.
do you have any news about this issue? Has somebody improved the ehci driver to avoid bits dropping?
Thank you, best regards.