Multichannel computer audio solutions

[phofman]

That really is a Windows idiosyncrasy.

Well, it is reality

I’ve never needed a driver for any of the numerous USB audio devices I’ve had over two or so decades with MacOS.

Linux UAC driver has lots of necessary quirks for many specific devices. How does the MacOS driver fare in this regard? Do vendors provide the quirks to Apple for inclusion to the stock driver?

Some pro-audio cards might come with additional drivers, but that’s because they offer functionality beyond what UAC2 offers. For simple DACs, nothing needed.

See above. UAC2 compliance does not seem to be so common, specially for UAC2 multichannel devices. Plus DSD is not part of UAC2 and requires vendor-specific quirks too.

 

[voodooless]

Linux UAC driver has lots of necessary quirks for many specific devices. How does the MacOS driver fare in this regard? Do vendors provide the quirks to Apple for inclusion to the stock driver?

Nope, not generally. It's plug and play, and has been for a long, long while.

 

[phofman]

I know, but what about the numerous devices which do require the quirk?

linux/sound/usb/quirks-table.h at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

linux/sound/usb/quirks.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

linux/sound/usb/mixer_quirks.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

On the other hand it's up to the vendor if his device is UAC2 compliant... Yet DSD is still N/A.

 

[voodooless]

I know, but what about the numerous devices which do require the quirk?

linux/sound/usb/quirks-table.h at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

linux/sound/usb/quirks.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

linux/sound/usb/mixer_quirks.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

On the other hand it's up to the vendor if his device is UAC2 compliant...

Yes, Linux seems to need some quicks occasionally. I have no idea what black magic MacOS uses to get by without these...

Yet DSD is still N/A.

MacOS generally will only support DSD via DoP.

 

[phofman]

Yes, Linux seems to need some quicks occasionally. I have no idea what black magic MacOS uses to get by without these...

The question is if those device which require linux quirks are really fully (to the level linux does) supported by MacOS out of the box, without vendor driver. My 2 cents not.

But the fact is a device can be built to fully support only the stock drivers - the linux f_uac2 gadget being an example.

 

[voodooless]

The question is if those device which require linux quirks are really fully (to the level linux does) supported by MacOS out of the box, without vendor driver. My 2 cents not.

There are at least several models in that quirk list that do not require a driver in macOS. Others might, but most of the hardware I checked is already so old that it's no longer supported anyway I guess in the early days, there still were issues with compatibility. Nowadays, much less so.

Yet, for Window, Topping, SMSL, and the like still provide a Windows driver, yet nothing is needed for macOS or Linux. I can understand that pro audio interfaces require much more than just audio in and out. So, additional drivers make sense for the added features.

 

[somebodyelse]

Linux UAC driver has lots of necessary quirks for many specific devices. How does the MacOS driver fare in this regard? Do vendors provide the quirks to Apple for inclusion to the stock driver?

Manufacturers are more likely to test with MacOS/iOS than they are with linux, and to make sure their implementation works with Apple's implementation. Claims of 'class compatible' seem to be shorthand for 'works with iOS' rather than any wider sort of compliance testing.