Where there are two clock domains it might take two Windows applications, one to play and other for input. Say, maybe a signal generator to play, and a signal analyzer to receive input. The two applications might be able to communicate with each other in some way if needed.
Other than that, ASIO4ALL supports something called a 'composite device.' Evidently it doesn't always work and or can result in increased latency.
Using two ASIO Devices in Windows 10 | Cakewalk Forums
Other than that, ASIO4ALL supports something called a 'composite device.' Evidently it doesn't always work and or can result in increased latency.
Using two ASIO Devices in Windows 10 | Cakewalk Forums
Can there be two ASIO drivers loaded by two apps at the same time? Maybe yes, I am not sure.
REW has an excellent generator and runs in separate threads from the analyzer, allowing to use different playback and capture devices.
IMO the composite mode in ASIO4All will never work 100% correctly, because it must merge two clock domains into one callback with fixed amount of samples. Which would not be needed if the capture could run asynchronously from the playback - what REW supports, as well as wasapi (or linux alsa) does.
REW has an excellent generator and runs in separate threads from the analyzer, allowing to use different playback and capture devices.
IMO the composite mode in ASIO4All will never work 100% correctly, because it must merge two clock domains into one callback with fixed amount of samples. Which would not be needed if the capture could run asynchronously from the playback - what REW supports, as well as wasapi (or linux alsa) does.
IIUC, two different programs can access two different ASIO devices on one PC at once. At least people have reported doing it successfully.
Regarding ASIO verses WASAPI Exclusive, suppose we agree to stipulate the latter is preferred for the reasons you outlined.
A possible remaining problem is that for audio devices, ASIO drivers remain much more common than WASAPI Exclusive drivers.
Also IIRC, last time I checked the minimum number licenses Thesycon will sell is 2,000 seats. Doesn't seem practical to go that route for small projects.
Of USB board manufacturers that sell I/O capable USB boards (so far we know about diyinhk and minidsp), only minidsp claims to have licensed WASAPI Exclusive drivers. That could make minidsp the vendor of choice for a USB solution, except perhaps that one neve knows when they will drop a product one may be relying on.
Regarding ASIO verses WASAPI Exclusive, suppose we agree to stipulate the latter is preferred for the reasons you outlined.
A possible remaining problem is that for audio devices, ASIO drivers remain much more common than WASAPI Exclusive drivers.
Also IIRC, last time I checked the minimum number licenses Thesycon will sell is 2,000 seats. Doesn't seem practical to go that route for small projects.
Of USB board manufacturers that sell I/O capable USB boards (so far we know about diyinhk and minidsp), only minidsp claims to have licensed WASAPI Exclusive drivers. That could make minidsp the vendor of choice for a USB solution, except perhaps that one neve knows when they will drop a product one may be relying on.
Well,
on ASIO exist's NONE "Multi Client Hosts" and "Multi Client Hosts". So with "Multi Client Hosts" various application may use same or different channel(s). With NONE "Multi Client Host" no share is possible. So that's why I have 3 ASIO engines for play and record. 😀
ASIO is as OLE1 implementation with DAW in mind with low latency as it gets and massive channels (as xxx) and the option to attach to a single of the possible of xxx. Latency to setup by the HW driver as x...xxxx bytes of the single buffer.
I did ASIO4All black listed as gets any trouble ... may for one it works
WASAPI (OLE2 based) at the beginning was not DAW proofed and any channel dealing in Exclusive mode may never possible. WASAPI GUI still with max of 384kHz but really 768kHz SR (or any other SR supported) to select by app 😀.
RME ADI-2 pro xx with UAC2 only with analog I/O (Stereo Mode) while multi channels as up to 192kHz not supported... this means given ASIO & driver to install and by by WASAPI & UAC2.
on ASIO exist's NONE "Multi Client Hosts" and "Multi Client Hosts". So with "Multi Client Hosts" various application may use same or different channel(s). With NONE "Multi Client Host" no share is possible. So that's why I have 3 ASIO engines for play and record. 😀
ASIO is as OLE1 implementation with DAW in mind with low latency as it gets and massive channels (as xxx) and the option to attach to a single of the possible of xxx. Latency to setup by the HW driver as x...xxxx bytes of the single buffer.
I did ASIO4All black listed as gets any trouble ... may for one it works
WASAPI (OLE2 based) at the beginning was not DAW proofed and any channel dealing in Exclusive mode may never possible. WASAPI GUI still with max of 384kHz but really 768kHz SR (or any other SR supported) to select by app 😀.
RME ADI-2 pro xx with UAC2 only with analog I/O (Stereo Mode) while multi channels as up to 192kHz not supported... this means given ASIO & driver to install and by by WASAPI & UAC2.
Hi HpW, do you think 768k mode makes sense? I decided to offer up to 32/384, however, 768k would increase the cost not so much. I am a bit afraid to use ES9822 2x mode, for that reason I go with NZ2520SD(49.152MHz) instead of the better one SG-210STF(24.576MHz).
Well, the AKM ADC 557x requires additional frequency response tuning by a DSP. Also at 768khz the noise shape rises as known and jitter rises as less decimation.
So the beef question is, how the ESS deals or behaves on that matter... would love to measure this figures( jitter behavior as compareded to AKM). Higher SR may nice for measurement purposes to see more as higher frequency '****' with better resolution as a DSO using 8..12 bit ADC...
But that's to complain to RME that they made their device incompatible with the MS UAC2 driver.
Attached is spectrum of 90kHz sine generated at 192/32bits/10 channels and played to wasapi exclusive UAC2 on Win10, captured and "spectrogrammed" on RPi4 UAC2 gadget. The black color corresponds to -180dB which means absolutely bitperfect transmission. RME could have used the very same driver for their multichannel 192kHz.
Why would you do that when the MS wasapi driver (licensed by MS from Thesycon) is available on every Win10 installation and apparently works just fine?
Attachments
Doesn't an app somehow still have to request Exclusive mode? What happens if it isn't granted? How would one know?
Also, When I look at audio devices available to Foobar2000, its rare to see one that says it is WASAPI Exclusive. Is it always there whether it is indicated or not? How would one know?
Thanks 🙂
Also, When I look at audio devices available to Foobar2000, its rare to see one that says it is WASAPI Exclusive. Is it always there whether it is indicated or not? How would one know?
Thanks 🙂
Last edited:
Wasapi was released several years after alsa and IMO MS devs got inspired to some extent. Some terminology is identical (e.g. period which AFAIK is used only in alsa and wasapi for the same thing).
IMO WASAPI exclusive is basically equivalent to linux alsa hw device. For WaveRT drivers the GetBuffer method can even return pointer to memory directly serviced by DMA of the sound device, just like alsa hw device does (and ASIO too). IMO every wasapi driver can be used in the exclusive mode, the shared mode is a common mixer provided by the OS on top of the raw driver.
I do not think the API contains a method to list only devices with the exclusive mode enabled by the user at the moment. Devices have a property PKEY_AudioEndpoint_Supports_EventDriven_Mode PKEY_AudioEndpoint_Supports_EventDriven_Mode (Mmdeviceapi.h) - Win32 apps | Microsoft Docs which is related to the least-latency event mode (equivalent to ASIO buffer_switch or alsa async callback). IMO if the device driver does not support event mode by itself the wasapi layer provides for it, as explained in Exclusive-Mode Streams - Win32 apps | Microsoft Docs .
IMO the standard way to detect availability is trying to open the device in exclusive mode. My testing code throws AUDCLNT_E_EXCLUSIVE_MODE_NOT_ALLOWED https://www.hresult.info/FACILITY_AUDCLNT/0x8889000E if the mode is disabled. Trying various options and observing the result is a common method for learning what modes, samplerates, sample formats, etc. a device supports at the moment.
I am testing the Foobar wasapi_output plugin for exclusive mode and do not see any information about exclusive in the device list in the config. Foobar works OK but is not 32bit-perfect.
The reason I am talking about it here is that IMO authors of new UAC2 devices could make their life and life of their customers/users easier if their devices supported the stock windows driver, not only some proprietary ASIO driver which non-corporate authors struggle to obtain. Perhaps that would motivate authors of measurement and analysis softwares to add/accept wasapi-exclusive support to their products.
Practical experience with requirements of the driver towards the devices could be compiled by the community, serving to everyone. AFAIK the only currently available know-how is contained in the existing and soon coming commits to the linux UAC2 gadget.
IMO WASAPI exclusive is basically equivalent to linux alsa hw device. For WaveRT drivers the GetBuffer method can even return pointer to memory directly serviced by DMA of the sound device, just like alsa hw device does (and ASIO too). IMO every wasapi driver can be used in the exclusive mode, the shared mode is a common mixer provided by the OS on top of the raw driver.
I do not think the API contains a method to list only devices with the exclusive mode enabled by the user at the moment. Devices have a property PKEY_AudioEndpoint_Supports_EventDriven_Mode PKEY_AudioEndpoint_Supports_EventDriven_Mode (Mmdeviceapi.h) - Win32 apps | Microsoft Docs which is related to the least-latency event mode (equivalent to ASIO buffer_switch or alsa async callback). IMO if the device driver does not support event mode by itself the wasapi layer provides for it, as explained in Exclusive-Mode Streams - Win32 apps | Microsoft Docs .
IMO the standard way to detect availability is trying to open the device in exclusive mode. My testing code throws AUDCLNT_E_EXCLUSIVE_MODE_NOT_ALLOWED https://www.hresult.info/FACILITY_AUDCLNT/0x8889000E if the mode is disabled. Trying various options and observing the result is a common method for learning what modes, samplerates, sample formats, etc. a device supports at the moment.
I am testing the Foobar wasapi_output plugin for exclusive mode and do not see any information about exclusive in the device list in the config. Foobar works OK but is not 32bit-perfect.
The reason I am talking about it here is that IMO authors of new UAC2 devices could make their life and life of their customers/users easier if their devices supported the stock windows driver, not only some proprietary ASIO driver which non-corporate authors struggle to obtain. Perhaps that would motivate authors of measurement and analysis softwares to add/accept wasapi-exclusive support to their products.
Practical experience with requirements of the driver towards the devices could be compiled by the community, serving to everyone. AFAIK the only currently available know-how is contained in the existing and soon coming commits to the linux UAC2 gadget.
Last edited:
As we have discussed earlier the Windows stock UAC2 driver has some quirks and limitations but once you get past those it works well. Have you tested it beyond 384k?
Do you have any info on REW WASAPI support?
I think I mentioned this before, although maybe in another thread, but with USB4 on the horizon, some of the issues with getting I2S in/out of a PC might change.
First of all, from what I understand, the big issue regarding multichannel, asynchronous, transfer at high data rates, with USB 2, is that no driver standard was created for USB 2 when it was released.
This being in contrast to USB 1 which had an audio standard and then had a bunch of stand alone silicon USB hardware audio interface chips being released as a result. No one could do this with USB 2 because any hardware had to come with its own unique driver = headache.
USB4, on the other hand, is set to include a new audio standard so stand alone silicon might be possible again. Not to mention that USB4 will allow the interface to act as an external PCI-E connection directly. In a couple of years we won't even need to use the USB standard to transmit data at all if we don't want to.
It kind of makes you think that if you were a developer you wouldn't even be bothering with anything new at the moment as it might all be obsolete shortly. I mean who would bother creating USB specific hardware if PCI-E can possibly do it all in the future? Unless the USB4 standard can be driverless.
First of all, from what I understand, the big issue regarding multichannel, asynchronous, transfer at high data rates, with USB 2, is that no driver standard was created for USB 2 when it was released.
This being in contrast to USB 1 which had an audio standard and then had a bunch of stand alone silicon USB hardware audio interface chips being released as a result. No one could do this with USB 2 because any hardware had to come with its own unique driver = headache.
USB4, on the other hand, is set to include a new audio standard so stand alone silicon might be possible again. Not to mention that USB4 will allow the interface to act as an external PCI-E connection directly. In a couple of years we won't even need to use the USB standard to transmit data at all if we don't want to.
It kind of makes you think that if you were a developer you wouldn't even be bothering with anything new at the moment as it might all be obsolete shortly. I mean who would bother creating USB specific hardware if PCI-E can possibly do it all in the future? Unless the USB4 standard can be driverless.
Hmm, don't think that's correct. There's a version 2.0 of the USB Audio Class specification (UAC-2). Audio Devices Rev. 2.0 and Adopters Agreement | USB-IF
And linux has a driver that implements that specification and supports many devices that adhere to this specification "out of the box". AFAIK macOS has such a driver, too.
And linux has a driver that implements that specification and supports many devices that adhere to this specification "out of the box". AFAIK macOS has such a driver, too.
He’s perfectly right. The UAC-2 spec leaves room for too much implementation wiggle, resulting in incompatibility issues. In particular, the USB2 multiplexing/polling is replaced in UAC-3 with point to point links, with its way to handle data polling, no more "pinging" the USB 2.0 interface, also providing a greatly reduced latency.
True, but with lots of quirks to work around "differences" in implementation of the standards.
A common misconception is the linkage between usb versions and the USB UAC audio versions. They are independent.
A common misconception is the linkage between usb versions and the USB UAC audio versions. They are independent.
UAC2 is a good example of design by committee. It is supposed to do absolutely everything, volume, routing, tone control, any app can control it, compatible, , yadda yadda. In other words, so complicated it will only work with the manufacturer's proprietary app.
Advertising again? Do you realize that it’s impossible to guess what is that Tweak9038 app doing (and honestly, I don’t even care) and you effectively provided zero helpful information in two posts?
Hm, I thought you should be interested in the info about ADC_INT_SEL register. Sorry, my mistake.