On Aug 28, 2007, at 1:50 PM, Cobey Gatos wrote:
What are the possible issues involved in declaring the device
transport type for a USB audio driver
"kIOAudioDeviceTransportTypeOther" instead of
"kIOAudioDeviceTransportTypeOther"? I understand that timestamps are
handled slightly differently for USB devices, and I am wondering how
important this difference is.
With the improvements in the USB Audio driver over the past few years,
the time stamp situation has more or less been dealt with at the
driver level. Consequently, the HAL stopped using the transport type
for controlling how it handles time stamp jitter a while ago.
That said, the transport type is still used by the HAL in two ways:
1) If an IOAudioEngine doesn't define the property,
kIOAudioEngineClockIsStableKey, the HAL uses the transport type to
determine this attribute (USB's clock is considered stable). A stable
clock means that the HAL can do some additional sanity checking on the
time stamps to ensure that they are valid and in the range the HAL is
expecting.
2) In the absence of any user-specified default device, the HAL uses
the transport type to order the search. It will choose FireWire, then
USB, then Built-In, and then anything else.
I added a call to set kIOAudioEngineClockIsStableKey in my engine's initHardware() function, and I have noticed that coreaudiod immediately crashes. This is on an Intel iMac running 10.4.10. I get the same result if I call setClockIsStable(true). Should I be setting this property somewhere else?
I ask because I have discovered that some applications, or at least
Cubase, will impose bandwidth limitations on my driver that prevent
it from working if I declare the device transport type as
"kIOAudioDeviceTransportTypeUSB". Declaring the device with
transport type "kIOAudioDeviceTransportTypeOther" works around the
problem.
I'm not at all sure what you mean by this. How can an app impose
bandwidth limitations on your driver?