C-Media: C-Media Electronics: C-Media Electronics Inc: Cambridge Silicon Radio Ltd: Canon: Canopus Co Ltd: Cardinal: Cherry GmbH: Chicony Electronics Co Ltd: Chips and Technologies: Chrontel Inc: Chu Yuen Enterprise Co Ltd: Chuntex (CTX) Cirrus Logic: Cirrus Logic - Ambient Technologies: Com1 sa: Compaq: Compaq Computer Corp: Compro: Conexant. Includes control protocols for Pro Tools, Live, Logic, Final Cut Pro, and Soundtrack Pro. NOTE: This updated driver is only needed for users who want to use the new Logic plug-in for AlphaTrack. Otherwise it is unchanged from the v1.2 Mac driver. AlphaTrack Macintosh Installer v1.4.1. V1.4 2010-11-15 AlphaTrackOSX141.zip - 1.8MB.
Starting with Windows 10, release 1703, a USB Audio 2.0 driver is shipped with Windows. It is designed to support the USB Audio 2.0 device class. The driver is a WaveRT audio port class miniport. For more information about the USB Audio 2.0 device class, see https://www.usb.org/documents?search=&type%5B0%5D=55&items_per_page=50.
The driver is named: usbaudio2.sys and the associated inf file is usbaudio2.inf.
The driver will identify in device manager as 'USB Audio Class 2 Device'. This name will be overwritten with a USB Product string, if it is available.
The driver is automatically enabled when a compatible device is attached to the system. However, if a third-party driver exists on the system or Windows Update, that driver will be installed and override the class driver.
usbaudio2.sys fits within the wider architecture of Windows USB Audio as shown.
The following USB specifications define USB Audio and are referenced in this topic.
The USB-IF is a special interest group that maintains the Official USB Specification, test specifications and tools.
The driver supports the formats listed below. An alternate setting which specifies another format defined in FMT-2, or an unknown format, will be ignored.
Type I formats (FMT-2 2.3.1):
Type III formats (FMT-2 2.3.3 and A.2.3):
This section describes the features of the USB Audio 2.0 driver.
The driver supports all entity types defined in ADC-2 3.13.
Each Terminal Entity must have a valid clock connection in compatible USB Audio 2.0 hardware. The clock path may optionally include Clock Multiplier and Clock Selector units and must end in a Clock Source Entity.
The driver supports one single clock source only. If a device implements multiple clock source entities and a clock selector, then the driver will use the clock source that is selected by default and will not modify the clock selector’s position.
A Processing Unit (ADC-2 3.13.9) with more than one input pin is not supported.
An Extension Unit (ADC-2 3.13.10) with more than one input pin is not supported.
Cyclic paths in the topology are not allowed.
The driver supports the following endpoint synchronization types (USB-2 5.12.4.1):
For the asynchronous OUT case the driver supports explicit feedback only. A feedback endpoint must be implemented in the respective alternate setting of the AS interface. The driver does not support implicit feedback.
There is currently limited support for devices using a shared clock for multiple endpoints.
For the Adaptive IN case the driver does not support a feedforward endpoint. If such an endpoint is present in the alternate setting, it will be ignored. The driver handles the Adaptive IN stream in the same way as an Asynchronous IN stream.
The size of isochronous packets created by the device must be within the limits specified in FMT-2.0 section 2.3.1.1. This means that the deviation of actual packet size from nominal size must not exceed +/- one audio slot (audio slot = channel count samples).
An audio function must implement exactly one AudioControl Interface Descriptor (ADC-2 4.7) and one or more AudioStreaming Interface Descriptors (ADC-2 4.9). A function with an audio control interface but no streaming interface is not supported.
The driver supports all descriptor types defined in ADC-2, section 4. The following subsections provide comments on some specific descriptor types.
For details on this specification, refer to ADC-2 4.9.2.
An AS interface descriptor must start with alternate setting zero with no endpoint (no bandwidth consumption) and further alternate settings must be specified in ascending order in compatible USB Audio 2.0 hardware.
An alternate setting with a format that is not supported by the driver will be ignored.
Each non-zero alternate setting must specify an isochronous data endpoint, and optionally a feedback endpoint. A non-zero alternate setting without any endpoint is not supported.
The bTerminalLink field must refer to a Terminal Entity in the topology and its value must be identical in all alternate settings of an AS interface.
The bFormatType field in the AS interface descriptor must be identical to bFormatType specified in the Format Type Descriptor (FMT-2 2.3.1.6).
For Type I formats, exactly one bit must be set to one in the bmFormats field of the AS interface descriptor. Otherwise, the format will be ignored by the driver.
To save bus bandwidth, one AS interface can implement multiple alternate settings with the same format (in terms of bNrChannels and AS Format Type Descriptor) but different wMaxPacketSize values in the isochronous data endpoint descriptor. For a given sample rate, the driver selects the alternate setting with the smallest wMaxPacketSize that can fulfill the data rate requirements.
For details on this specification, refer to FMT-2 2.3.1.6.
The following restrictions apply:
Format | Subslot size | Bit resolution |
---|---|---|
Type I PCM format: | 1 <= bSubslotSize <= 4 | 8 <= bBitResolution <= 32 |
Type I PCM8 format: | bSubslotSize 1 | bBitResolution 8 |
Type I IEEE_FLOAT format: | bSubslotSize 4 | bBitResolution 32 |
Type III IEC61937 formats: | bSubslotSize 2 | bBitResolution 16 |
For details on this specification, refer to ADC-2 4.10.1.2.
The MaxPacketsOnly flag in the bmAttributes field is not supported and will be ignored.
The fields bmControls, bLockDelayUnits and wLockDelay will be ignored.
The driver supports a subset of the control requests defined in ADC-2, section 5.2, and supports interrupt data messages (ADC-2 6.1) for some controls. The following table shows the subset that is implemented in the driver.
Entity | Control | GET CUR | SET CUR | GET RANGE | INTERRUPT |
---|---|---|---|---|---|
Clock Source | Sampling Frequency Control | x | x | x | |
Clock Selector | Clock Selector Control | x | |||
Clock Multiplier | Numerator Control | x | |||
Denominator Control | x | ||||
Terminal | Connector Control | x | x | ||
Mixer Unit | Mixer Control | x | x | x | |
Selector Unit | Selector Control | x | x | ||
Feature Unit | Mute Control | x | x | x | |
Volume Control | x | x | x | x | |
Automatic Gain Control | x | x | |||
Effect Unit | – | ||||
Processing Unit | – | ||||
Extension Unit | – |
Additional information on the controls and requests is available in the following subsections.
For details on this specification, refer to ADC-2 5.2.5.1.
At a minimum, a Clock Source Entity must implement Sampling Frequency Control GET RANGE and GET CUR requests (ADC-2 5.2.5.1.1) in compatible USB Audio 2.0 hardware.
The Sampling Frequency Control GET RANGE request returns a list of subranges (ADC-2 5.2.1). Each subrange describes a discrete frequency, or a frequency range. A discrete sampling frequency must be expressed by setting MIN and MAX fields to the respective frequency and RES to zero. Individual subranges must not overlap. If a subrange overlaps a previous one, it will be ignored by the driver.
A Clock Source Entity which implements one single fixed frequency only does not need to implement Sampling Frequency Control SET CUR. It implements GET CUR which returns the fixed frequency, and it implements GET RANGE which reports one single discrete frequency.
For details on this specification, refer to ADC-2 5.2.5.2
The USB Audio 2.0 driver does not support clock selection. The driver uses the Clock Source Entity which is selected by default and never issues a Clock Selector Control SET CUR request. The Clock Selector Control GET CUR request (ADC-2 5.2.5.2.1) must be implemented in compatible USB Audio 2.0 hardware.
For details on this specification, refer to ADC-2 5.2.5.7.
The driver supports one single volume range only. If the Volume Control GET RANGE request returns more than one range, then subsequent ranges will be ignored.
The volume interval expressed by the MIN and MAX fields should be an integer multiple of the step size specified in the RES field.
If a feature unit implements single channel controls as well as a master control for Mute or Volume, then the driver uses the single channel controls and ignores the master control.
OEMs and IHVs should test their existing and new devices against the supplied in-box driver.
There is not any specific partner customization that is associated with the in-box USB Audio 2.0 driver.
This INF file entry (provided in a update to Windows Release 1703), is used to identify that the in-box driver is a generic device driver.
The in-box driver registers for the following compatible IDs with usbaudio2.inf.
See the USB audio 2.0 specification for subclass types.
USB Audio 2.0 Devices with MIDI (subclass 0x03 above) will enumerate the MIDI function as a separate multi-function device with usbaudio.sys (USB Audio 1.0 driver) loaded.
The USB Audio 1.0 class driver registers this compatible ID with wdma_usb.inf.
And has these exclusions:
An arbitrary number of channels (greater than eight) are not supported in shared mode due to a limitation of the Windows audio stack.
For IHV provided third party driver USB Audio 2.0 drivers, those drivers will continue to be preferred for their devices over our in-box driver unless they update their driver to explicitly override this behavior and use the in-box driver.
Starting in Windows 10 release 1703, IHVs that create USB Audio Class 2.0 devices having one or more jacks have the capability to describe these jacks to the in-box Audio Class 2.0 driver. The in-box driver uses the supplied jack information when handling the KSPROPERTY_JACK_DESCRIPTION for this device.
Jack information is stored in the registry in the device instance key (HW key).
The following describes the audio jack information settings in the registry:
<tid> = terminal ID (As defined in the descriptor)
<n> = Jack number (1 ~ n).
Convention for <tid> and <n> is:
For example:
T1_NrJacks, T1_J2_ChannelMapping, T1_J2_ConnectorType
For additional audio jack information, see KSJACK_DESCRIPTION structure.
These registry values can be set in various ways:
By using custom INFs which wrap the in-box INF for the purpose to set these values.
Directly by the h/w device via a Microsoft OS Descriptors for USB devices (see example below). For more information about creating these descriptors, see Microsoft OS Descriptors for USB Devices.
The following Microsoft OS Descriptors for USB example contains the channel mapping and color for one jack. The example is for a non-composite device with single feature descriptor.
The IHV vendor should extend it to contain any other information for the jack description.
If the driver does not start, the system event log should be checked. The driver logs events which indicate the reason for the failure. Similarly, audio logs can be manually collected following the steps described in this blog entry. If the failure may indicate a driver problem, please report it using the Feedback Hub described below, and include the logs.
For information on how to read logs for the USB Audio 2.0 class driver using supplemental TMF files, see this blog entry. For general information on working with TMF files, see Displaying a Trace Log with a TMF File.
For information on 'Audio services not responding' error and USB audio device does not work in Windows 10 version 1703 see, USB Audio Not Playing
If you run into a problem with this driver, collect audio logs and then follow steps outlined in this blog entry to bring it to our attention via the Feedback Hub.
This USB Audio 2.0 class driver was developed by Thesycon and is supported by Microsoft.
Their are two major Radio-Computer connection channels, CAT and Audio...
CAT is what allows an application to communicate with the radio's VFO, setting and reading frequencies and modes. Almost all Amateur radios (excluding the new LAN based radios) operate CAT communication over a very old RS-232 protocol - even if the radio is using a modern USB interface, the protocol is still 60 year old RS-232 over USB. Unlike modern self-configuring devices the setup parameters found in the Radio's menus must match the settings in the application preferences exactly. This can be challenging to get right the first time but the application should remember the settings for you after that.
Since most older radios have old style TTL or RS-232 connections for this channel and most computers have abandoned these old style serial ports, we need to add a USB-to-Serial adapter to the computer. This is usually a simple piece of hardware (UART) accompanied by a Mac software driver that allows the application to 'see' the radio connected to this device. The device may also include level converters to convert the RS-232 to the TTL level required by the (older) radio and sometimes DTR and RTS lines to also let the computer key the radio's PTT and CW lines.
Some devices combine the above capabilities with digital CW generators and or sound cards (modems) for the Audio channel.
Some radios have the USB/Serial adapters built in and only require a USB cable connecting them to the computer but still require a Mac driver to be installed.
The audio channel allows the computer to send pre-recorded speech or digitally encoded information (RTTY, PSK etc.) to the radio's microphone or accessory jack as well as receive digitally encoded data from the radio's headphone or accessory jack for decoding. Some radios have this sound card capability built into the radio and it can be accessed over the same USB cable as the CAT channel. Sound cards on the Mac do not normally require a driver to be installed and can be configured in the Mac System Preferences Sound panel.
If you don't see the USB/Serial adapter port connected to your radio in the Port popup (or all you see is a Bluetooth port) then it could be one of the following:
You can tell which chip set is being used in your adapter/radio by selecting 'About This Mac / Overview / System Report / Hardware / USB. If the UART shows up in the Hardware/USB report It means that it is plugged in and powered up - not that a driver is necessarily loaded. Once you have identified the UART Chip set (FTDI, Silicon Labs, Prolific, Keyspan/Tripplite, RT Systems etc.) you can download and install the Mac driver from the manufacturers web site.
The USB/UART Bridge chip inside the Icom, Yaesu and Kenwood radios is a Silicon Labs USB to UART Bridge Controller and the Mac drivers are available here.
The USB/UART Bridge chip inside the Eagle, K3S and KX3 is an FTDI USB to UART Bridge Controller and the Mac drivers are available here.
Note: macOS built in FTDI driver: Supports FTDI based devices with standard VID/PID combinations.
'Since 10.9 (Mavericks), OS X has included built-in partial support for some FTDI devices in VCP mode. Starting with 10.11 (El Capitan), Apple’s own driver seems to be sufficiently comprehensive that many customers will not need to install FTDI’s own VCP unless they wish to use its advanced features such as baud-rate aliasing and configurable latency times' .
You can tell which driver is installed and loaded by selecting 'About This Mac / Overview / System Report / Software / Extensions. and looking for the kernel extension that matches the adapter chip set (eg FTDI, Silicon Labs, Prolific etc.) It’s important that the driver is Loadable and Signed. It will only show as Loaded when the device is powered up and plugged in.
Make sure you have the correct version of the driver installed for your version of macOS - for example, the latest Silicon Labs driver will not work with macOS 10.9 or 10.10 and you need to install their legacy driver.
Don’t forget that the System Report does not automatically refresh and can take up to a minute to display all the extensions. If you want to see if a change you made (plugging/unplugging/changing usb ports etc.) has caused the driver to load then you have to go through the system report steps again - or run the application and look at the debug log for the loaded driver.
Radio still not showing up ?
Other things to try...
Drivers (kernel extensions) can be tricky to install on High Sierra (and later) if you are doing it for the first time, but if you want to communicate with your radio using MacLoggerDX, MacDoppler or any other Ham Radio software you will need to install the driver supplied by the manufacturer of the UART in your radio or radio adapter. It is not possible for MacLoggerDX or MacDoppler to do this for you.
Note: macOS built in FTDI driver:
'Since 10.9 (Mavericks), OS X has included built-in partial support for some FTDI devices in VCP mode. Starting with 10.11 (El Capitan), Apple’s own driver seems to be sufficiently comprehensive that many customers will not need to install FTDI’s own VCP unless they wish to use its advanced features such as baud-rate aliasing and configurable latency times' .
Starting with OS X Mavericks, Apple has been making changes to how third party kernel extensions are allowed to work. On macOS High SIerra and later, kernel extensions must be digitally signed using an Apple Developer ID and installed into /Library/Extensions enforced by System Integrity Protection. Kernel extensions will not load unless authorized to do so by a logged-in user.
User-Approved Kernel Extension Loading
macOS High Sierra 10.13 introduces a new feature that requires user approval before loading new third-party kernel extensions. (Approval is automatically granted to third-party KEXTs that were already present when upgrading to macOS High Sierra).
When a request is made to load a KEXT that the user has not yet approved, the load request is denied and macOS presents this alert.
This prompts the user to approve the KEXT in System Preferences / Security & Privacy / General.
You will have to enter your credentials after clicking the lock in the lower left corner to enable the Allow button.
This approval UI is only present in the Security & Privacy preferences pane for 30 minutes after the alert. Until the user approves the KEXT, future load attempts will cause the approval UI to reappear but will not trigger another user alert..
Once approved, the KEXT will immediately be loaded or added to the prelinked kernel cache, depending on what action was blocked. Subsequent requests to load the KEXT will proceed silently as on previous macOS versions.
Apple Technical Note TN2459