Apple

Thanks Alison,

Our device is not class compliant

I highly recommend making your device class compliant. It improves your customers' experience, reduces your R&D/support costs, and greatly expands your test coverage. We are working hard to support developers in this goal.

Taking the AUA sources, modifying them to shortcut development, and then releasing them as your own driver without complete understanding can get you into trouble, especially as OS updates and new CPU products are released. With a solid class compliant solution, your device should continue to work over many OS releases without any additional development work. If you find areas that you were able to improve in AUA, please send those changes/suggestions back to us via Bug Reporter so we can all benefit. This is the point of having the driver available as open source, as well as to help educate how the software works (see <http://www.apple.com/opensource/>.)

so I need to make a few modifications like the way we set our clock and comment out the check for feedback endpoint(which was failing even though we have one and works under windows).

Please send us a bug report if you think you've found an issue.

Although the feedback endpoint implementation has been working for some time, the precision in the calculation has been slightly improved in the last year. It works according to the 1.0 and 2.0 USB Audio Device Class specifications (<http://www.usb.org/developers/devclass_docs#approved>) and has tested well with several existing class compliant USB audio devices i.e. streaming artifact-free asynchronously for multiple days at high bandwidth. I am not aware of any outstanding issues in this area.

So I need to modify info.plist to get our vendor and product ID recognized but that should be simple and I assume that won't impact getting the two streams into one engine.

--Chuck

On Mon, Jul 12, 2010 at 11:12 AM, Alison Hughes <email@hidden> wrote:
Chuck,

If you use our class driver, there is no need to modify the info.plist - AppleUSBAudio will attempt to put the streams on a single engine automatically depending on the device configuration. From the section titled "Unified Engine Model" in our tech note "USB Audio on the Mac":

In order to combine multiple streams on one engine, the following criteria must be met by the stream interfaces:

• All sample rate sets must match.
• The same synchronization type is used for all interface alternate settings.
• The streams reside in the same clock domain.

See <https://developer.apple.com/mac/library/technotes/tn2010/tn2274.html#TNTAG3> for more info.

Thanks,
Alison

--------------------
Alison Hughes
CPU Software Engineering (Audio)
Apple, Inc.

On Jul 11, 2010, at 8:46 PM, Chuck Carlson wrote:

> Hello,
>
> A while ago I implemented our usb audio driver for 10.5.6. Our device requires one audio engine with two streams. This required much ugly butchering of the standard apple driver.
>
> Now I'm doing the same job, but with the latest driver, AppleUSBAudio-273-4.1 for 10.6.4. The model now supports input and output streams in one engine. (seems this is true since 10.5.7).
>
> What's the simplest way to do this?
>
> I'm assuming there is something simple to put into the info.plist which will cause the iokit matching to put the streams into one engine, but can't figure it out.
>
> Thanks for any pointers,
>
> --Chuck

> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden