On Nov 28, 2011, at 12:44 AM, Brian Willoughby wrote:
> Top question: Does the Isochronous IN endpoint have to work perfectly before a new USB Audio Class Device will appear in Audio MIDI Setup? I have not been able to test my ISO endpoint because my Descriptors don't seem to make CoreAudio happy. I've been laboring under the assumption that I can start by getting the Descriptors correct, see my Device in AMS, then start debugging my ISO IN transfers (hopefully without too many serious errors, otherwise CoreAudio could get really unhappy).
In my experience, EVERYTHING has to be correct before it'll work. Or, at least, the descriptors have to be correct, because if they are not, then the OS has no way of knowing how the device expects to work. So it needs proper Terminals so the OS knows how audio data are to be routed and what Features are supported. And the endpoints need to have proper buffer sizes, etc.
> I also assume that my ISO IN endpoints will not be activated until some CoreAudio client opens my microphone device for recording, but I'm guessing that it's possible CoreAudio might run a quick test (for 20 seconds?) that my device firmware fails.
The audio IN interface should not be activated until an app needs to use it.
>
> More below...
>
>
> On Nov 27, 2011, at 14:45, Andy Peters wrote:
>> On Nov 27, 2011, at 2:41 AM, Brian Willoughby wrote:
>>> I am developing firmware for a USB Audio Class 1.0 input device which is marked as a Microphone. It has 4 channels of 12-bit (16-bit) audio at 125 kHz. USB Prober seems happy to display my device when attached (after about 20-seconds of delay), but it does not appear in Audio MIDI Setup. I assume that I may need to add a Feature or other Unit before AMS will display my device.
>>>
>>> Is there any documentation as to what I need to support in order to allow my device to be used for audio input?
>>>
>>> So far, I have tested on 10.4.11 since I hope to maintain maximum compatibility across Mac platforms. This also explains why I am starting with USB Audio Class 1.0 instead of 2.0 (my device is Full Speed).
>>>
>>> Note: For the channel count, bit depth, and sample rate of my device, the maximum packet size turns out to be 1008 bytes, which seems within the capabilities of the system. I also tried 1000 bytes with no difference.
>>
>> You need to have all of the various Feature Units and Terminals set up (Mic Input Terminal, Feature Unit for gain if hardware supports it, USB In terminal). These are necessary for all input channels. My two-input device has these and it shows up in AMS fine. My device also enumerates as Audio Class 1.0 because a) it doesn't need High Speed and b) it can't support the various other things required by 2.0.
>>
>> The documentation I used was the USB Audio Class reference and a couple of TI's examples.
> Thank you for the reply. Which TI examples did you reference? I happen to be writing firmware for the TMS320VC5506, which does not have any USB Audio Class examples. They do provide examples for the High Speed members of this family, but not the Full Speed members.
Look for their TAS1020B (which was listed as NRND yesterday!) firmware examples. These examples aren't all that great and their example code kinda sucks.
> I implemented the Descriptors from Appendix B of the Audio Class 1.0 document, changing only the channel counts, bit depth, and sample rate. That example has only an Input Terminal (Mic) and Output Terminal (USB) with no Feature Units. My hardware does not support gain, so this seems appropriate.
>
> I decided to try with mono instead of quad, so that my Descriptors almost perfectly match the UAC1 appendix B example.
>
> There may be something amiss because I grabbed a USB Audio interface and it did not show up either, until I rebooted my Mac. Perhaps my Descriptors confused the USB Audio driver. Now that I've rebooted, the commercial USB Audio interface appears in AMS, but mine does not. I can remove and insert the commercial device and AMS responds appropriately, but my device gets no response except from USB Prober (where it takes about 20 seconds for my device to appear instead of the usual instantaneous response).
>
> Here are the Descriptors from USB Prober:
(snip)
> Interface #0 - Audio/Control
> Alternate Setting 0
> Number of Endpoints 0
> Interface Class: 1 (Audio)
> Interface Subclass; 1 (Control)
> Interface Protocol: 0
> Audio Control Class Specific Header
> Descriptor Version Number: 01.00
> Class Specific Size: 30
> Number of Audio Interfaces: 1
> Audio Interface Number: 1
> Dump Contents (hex): 09 24 01 01 00 00 1E 01 01
> Audio Class Specific Input Terminal
> Terminal ID: 1
> Input Terminal Type: 0x201 (Microphone)
> OutTerminal ID: 0 [NONE]
> Number of Channels: 1
> Spatial config of channels: 0000000000000000
I believe that you need to indicate at least one of the bits in the field wChannelConfig are set, even for a mono input. I think just setting the LSb to tell it "left channel" should suffice. For your quad interface, set at least four of the bits.
Now, my devices have been simple two input jobs, so I don't know how the OS will actually interpret these bits (especially Windows).
The USB Audio Class 1.0 spec says on page 34 that "If none of the bits in wChannelConfig are set, then all channels have non-predefined spatial positions." This whole concept is rather silly but it's worth a shot setting some bits and seeing what happens.
-a _______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
