Originally, the ADICON was intended as a pure analog-to-digital converter only, a device meant to serve as a link between fine and possibly vintage analog audio equipment and modern digital systems. A link to PCs was not intended. Except possibly via the digital audio signal, provided the PC is equipped with a digital audio input.
It was too obvious that demands for a USB interface would be high. It is not too difficult to implement a USB Audio Class 1 interface which is able to handle low sample rates only. But USB Audio Class 2 interfaces, which are able to handle higher sample rates, are not trivial to implement at all and maybe out of reach for us. Thus, even though we believed that this is not adequate for the ADICON, we started with a simple USB Audio Class 1 interface. Later we got the opportunity to design a USB Audio Class 2 interface, too, and we took it. These are our plans:
Design State | Type | Sample Rates (kHz) | Bits |
Special Driver for OS X and Linux |
Special Driver for Windows |
When the Sample Rate Changes: |
First approach: USB Audio Class 1 Interface |
USB Audio Class 1 | 44.1, 48 | 16 | No | No |
PC application and ADICON settings must be identical |
Originally intended: Combined USB Audio Class 1 and USB Audio Class 2 Interface |
USB Audio Class 1 | 44.1, 48, 88.2, 96 | 24 | No | No |
The current device disappears, a new device which offers only the new sample rate appears and must be selected manually by the user |
USB Audio Class 2 | 176.4, 192 | 24 | No | Yes | ||
Finally achieved: Combined USB Audio Class 1 and USB Audio Class 2 Interface |
USB Audio Class 1 | 44.1, 48, 88.2, 96 | 24 | No | No | |
USB Audio Class 1 (Windows) | 176.4, 192 | 16 | No | No | ||
USB Audio Class 2 (OS X and Linux) | 176.4, 192 | 24 | No | No |
Such a technology like USB Audio Class 2 is not just simply "available" or "not available". It is more complex to explain the situation and also to design such an interface. Amongst others, we need to differentiate between the PC side (drivers) and the device side (e.g., the ADICON).
USB Audio Class 1 is specified by the USB committee for USB 1.2 interfaces (up to 12 MBit/s) and thus able to handle low bandwidths only, e.g. 48 kHz with 16 or 24 bits (Single Speed mode) bidirectional or 96 kHz / 24 (Dual Speed mode) bits unidirectional or 192 kHz / 16 bits (Quad Speed mode) unidirectional. USB Audio Class 1 drivers are implemented on all relevant operating systems, including Windows, OS X and Linux. USB Audio Class 1 interface ICs are available, but the variety is limited: The only IC we know that seems to be able for 96 kHz / 24 bits doesn't seem to be available any more. Moreover, would it be available, we wouldn't know whether we could rely on it because we have special requirements that probably couldn't be met by this IC. The only IC that is available supports up to 48 kHz and 16 bit only, thus in our first approach we went for that.
USB Audio Class 2 is specified by the USB committee for USB 2.0 interfaces (up to 480 MBit/s) and thus able to handle high bandwidths, multichannel applications and much more. Unfortunately USB Audio Class 2 is not supported by Windows. OS X and Linux do support USB Audio Class 2. As USB Audio Class 2 is not supported by Windows the situation for hard- and software is much more complicated. While it is true that for hard- and software a few solutions are available it is not just a matter of buying and using them.
Externally determined sample rates: Moreover, on the driver side we experienced that the implementations we know (OS X and Linux) are not complete. At USB Audio Class 1 it is assumed that always the PC commands the sample rate. There is no provision for changing the sample rate externally like we do it on the ADICON, which is primarily a stand-alone device, independent of any PC. This should be different with USB Audio Class 2 where it should be permissible that the sample rate is determined by an external device. But both driver implementations we learned to know do not support this feature. I.e., commands that are provided for changing the sample rates externally are not respected by the driver.
Thus we are going our own way. Primarily we are very lucky to know somebody who is very skilled do do the necessary design process for us. We intend to design a USB interface based on a µC that is able to handle USB 2.0 High Speed (480 MBit/s). For speeds up to 96k / 24 and 196k / 16 we implemented a USB Audio Class 1 interface which can be used with all operating systems without a special driver. For speeds above 96k and 24 bits we implemented a USB Audio Class 2 interface which can be used with OS X and Linux without a special driver. For Windows we did not yet create a proprietary driver which would be a small subset of USB Audio Class 2 functionality.
The way out that we took for the issue of changing the sample rates is that for both, USB Audio Class 1 and 2, the device (our ADICON) will log out when the sample rate is changed and afterwards log in again as a new device with the actual sample rate. Would we design our interface compliant to the USB 2.0 specifications, it obviously would not work on any PC. A really strange situation.
USB Audio Class 1 / 2 changeover: For Windows, where the Quad Speed mode is possible with USB Audio Class 1 and 16 bits only, the trick is: When the ADICON runs in Quad Speed mode and the interface is connected to a PC it starts as a USB Audio Class 2 interface. A Windows PC cannot configure such an interface. Thus, should it not be configured as a USB Audio Class 2 interface within the next 30 seconds after connection, it disappears and reappears in USB Audio Class 1 mode where it is most likely that it can be configured.
Last update: June 1st, 2015 | Questions? Suggestions? Email Me! | Uwe Beis |