Do you think we are really going to use ASIO4ALL ?

I am on pc, and sometimes a mac. Usually a PC running cubase with a UR824 audio interface, with it's own low latency ASIO drivers. So, now if I want to "pass thru" ipad synth audio (as advertised) I have to ditch my well made ASIO device drivers and use ASIO4ALL (an useful, but inferior generic driver) Are you guys serious about this? I'm getting ready to box this up and return it. Is there any work around for this? This is a deal breaker for me.


  • edited August 2015
    Hey Duckteasah - this is currently the only way to pair WDM and ASIO devices, since ASIO is typically designed to focus on one hardware and one application - to maximize performance.

    Are you having latency issues, or have you not had a chance to set it up?
    ASIO4ALL does not really cause significant latency itself (actually some windows users will report a better performance using it with a WDM device with an application that supports ASIO devices), typically you will see the additional latency from pairing your hardware in general. But this can typically be controlled by the latency buffering settings in your DAW, iOS apps, and iConfig Audio menu. (I see a little latency change when using Aggregate Devices on OS X as well, so it not necessarily related to ASIO4ALL's implementations)

    Let me know how I can assist further,
  • edited August 2015
    Hi Josh,

    This idea that ASIO is single device and/or single client is not completely accurate AFAIK. Maybe I'm misunderstanding, but AFAIK plenty of multi-device ASIO implementations exist, but they are typically limited to devices from the same manufacturer. This is because the driver must be common to the devices for robust clocking and caching. But that doesn't mean multiple iConnectivity devices cannot share drivers in a manner which currently only works via ASIO4ALL aggregation. Due to the multi-device ASIO implementations of products within some manufacturer's product ranges, I expected the iCM4+ and iCA4+ to have such capabilities and was really disappointed to discover coupling/chaining (aggregation at driver level and within driver control panel) was out of the design scope.

    ASIO4ALL is actually a wrapper around WDM. This is ironically funny from Wikipedia: "A popular alternative is to use the ASIO4All driver by German programmer Michael Tippach, which can often deliver low latency on soundcards that __have not been designed with music production in mind__."

    Is it possible to couple/chain two iCA4+ devices without ASIO4ALL? They would use the same driver, so it should be possible. I'd buy an extra iCA4+ in a flash if that can be done. Then my iCM4+ could be dedicated to MIDI alone.

    The companies which have products offering multi-device ASIO support develop their own drivers instead of outsourcing driver development. AFAIK, iConnectivity outsources driver development and is therefore subject to the development/delivery time frames of external companies. It also doesn't seem like a good recipe for delivering innovation (which to me seems to be the core business of iConnectivity - you guys are remaking what's possible for iOS users, for example)

    The problem with ASIO4ALL is the lack of ongoing support (or the lack of _any_ support) from Michael Tippach. It's basically abandonware. If ASIO4ALL doesnt work well with Windows 10 (for example), there is nothing iConnectivity can do to rectify that.

    It's a hard policy to understand despite Mike's explanation regarding the cost and time required for in-house driver development, as the iConnectivity products are designed from the ground up as multi-device interfaces. It's one thing to assert that best policy is to strictly follow USB class compliance, but OTOH, that doesn't seem like a powerful argument for pushing your customers towards a third party solution without any support from that third party. Building USB drivers which are class compliant but also include additional functions for iConnectivity devices would seem to be the logical approach. There is nothing wrong with using proprietary device drivers if it achieves better functionality, better reliability and ongoing support from the driver developers.

    Perhaps I'm misunderstanding something?

Sign In or Register to comment.