ASIO audio backend

My clients, in their infinite wisdom, have swapped out an audio card at the last minute of a project that appears to only support ASIO, which apparently makes it invisible to my cinder based audio application. (Which is, of course, my fault somehow, but I digress). Looking at the cinder source, it seems I only need to port the device manager and context classes to ASIO from WASAPI, but since I know next to nothing about audio programming, and have basically zero time to do this, I thought I’d ask those much smarter than I if it’s a complete fools errand.

My first suggestion was for them to go fuck themselves, closely followed by potentially using a virtual ASIO to WDM middleware (, but while they investigate the feasibility of the second route (the first was dismissed out of hand, unfortunately), I thought I’d see if any prior art or knowledge exists. @rich.e, in particular might know what’s up.

Thanks a lot, and sorry for the potty mouth, i’m in full blown crunch mode. :angry:


Hah. Out of curiosity, what is the audio card and why did they make the change?

The virtual ASIO -> WASAPI thing might get you there at the cost of a bit of extra latency (who knows). It would be great if we had a ContextAsio until WASAPI (especially in low latency mode) is more widely supported, but that hinges on development resources. An easier alternative would be to make a portaudio backend, and then target ASIO with that. Portaudio is fairly easy to get up and running even without much knowledge of audio backends. Feel free to PM me however you can if you think it would help.

On the other hand, hope you can convince them to use hardware that is supported by the software you’re using, if that doesn’t make too much sense… :slight_smile:

I have actually no idea what ASIO is (in an audio context), but I think FMOD supports it. Cinder comes with an FMOD block. If the block does not provide a solution, it’s actually pretty easy to get FMOD up and running yourself. Would that be a solution?


Unfortunately it revolves pretty heavily around the node design of ci::audio so that would pretty much be a rewrite. If i do end up having to rewrite FMOD is likely the way i’ll go, so thanks.

Dante is the name of the card, and it seems the change was made for no reason other than to make my life miserable. I’ve yet to get a concrete reason out of anyone. Thanks for the PortAudio suggestion.

Hello everyone,

I’m developing an audio analyzer with Cinder and have been playing with FMOD, Cinder monitor nodes, FFT, etc. and was curious what you decided to do lithium.snepo with regards to using ASIO support for your app.

I’m interested in ASIO audio support since many pro audio devices use it for low latency streaming and I would like to use those streams as input.

How did you resolve the ASIO issue, if at all? Thanks…!

I think they ended up using some wacky incantation involving AsioLinkPro and possibly asio4all as a stop gap measure, and likely my first duty when our office reopens will be to learn what the ASIO is all about and either rewrite my application or port the cinder wasapi backend to ASIO. (Side note, i’m leaning away from this course of action, but of course i will submit it as a PR if I do end up going that way)

Sorry I don’t have a more concrete solution for you.


… or port the cinder wasapi backend to ASIO

I’d very much welcome some work along these lines, my focus for the forseeable future will continue to be on the WASAPI layer but if I can help in getting an ASIO-based audio::Context in there, there is obviously room for it still. Note though that we can’t ship the required ASIO lib binaries, you’d have to install those separately. This was one of the motivating factors behind choosing WASAPI for our base audio hardware layer on windows, that and the MS team is actively improving it to the point that hopefully one day ASIO will be obsolete.

Yeah mate, that’s a good chunk of why I’m leaning away from going that route, though as a purely educational exercise, I’m sure one could do a lot worse.

Ok thanks…was just wondering what direction you may have taken to solve your problem.

I’ve been reading a lot in about WASAPI and it’s evolution in various audio programming/hardware forums and many echo your thoughts regarding it; ditching ASIO, if/when possible, would be welcomed indeed. Unless the hardware device has native ASIO drivers, you’re stuck using ASIO4ALL, etc. which has mixed results/performance depending on the hardware/software, etc. Would be nice to have that type of functionality with a native API/drivers.