ASIO SDK rewritten for C code?

[James Perrett]

If you want them I can send them to you. It could save you some time.. I've not tested any yet, but I will enter that rabbit-hole later, at my own expense, and with some red pills.

Thanks for the offer but the file name was enough to allow me to find them. I'll let my son know about them.

This might give you pause..

Just installing Behringer's drivers today has ruled out Behringer for general Windows use. They don't even care to support their own drivers (or we'd not need Wayback to find them), and installation was like the bad old days of driver hell in W95. They kept demanding sysfiles that were IN the system, and that's when they didn't lock up WXP trying, even with driver versions intended for that OS.

I think you are asking too much. There was obviously a good reason why Behringer decided not to supply ASIO drivers for that range of interfaces and you've just found it! If you want ASIO then use an interface that supports it rather than try to cobble something together from stuff you've found on the net. As I said in my previous post - if you want proper ASIO then you will need a Behringer UMC0202HD or better - in my experience the drivers for that install with no problems.

Edit to add:- those cheap Behringer interfaces also have other issues which limit their usefulness for serious work in my experience.

[Lostgallifreyan]

I think you are asking too much. There was obviously a good reason why Behringer decided not to supply ASIO drivers for that range of interfaces and you've just found it! If you want ASIO then use an interface that supports it rather than try to cobble something together from stuff you've found on the net. As I said in my previous post - if you want proper ASIO then you will need a Behringer UMC0202HD or better - in my experience the drivers for that install with no problems.

Edit to add:- those cheap Behringer interfaces also have other issues which limit their usefulness for serious work in my experience.

I agree, but those were Behringer's drivers. This about-turn of theirs makes me nervous, but I may try the UMC202HD when I get over this, if I've not settled on something else before then. (Mic preamps and physical controls push the price up, I'd settle for a very basic I/O with line level, if its drivers work.)

I don't mind wasting a little time trying the cheap end first. NASA dropped a few things too before they got stuff up there.. I don't mind failing if it tells me something I can use later.

[BJG145]

I've found ASIO4ALL to be poor for latency, obscure and flakey to set up and generally a bit of a bodge.

Agreed, I've used dozens of different types of audio interfaces as we doubtless all have, and ASIO4ALL is a last resort.

[The Elf]

I've found ASIO4ALL to be poor for latency, obscure and flakey to set up and generally a bit of a bodge.

Agreed, I've used dozens of different types of audio interfaces as we doubtless all have, and ASIO4ALL is a last resort.

I realise that what I wrote made me sound ungracious. ASIO4ALL is a last resort, but it does work, and it's good to know it's there. That it does what it does at all is a minor miracle, and has saved me lots of time and trouble over the years.

[tea for two]

Before I started purrchasing usbClassCompliant audio midi devices, I used ASIO4All a fair amount with CakeWalk Sonar because as a catch all ASIO4ALL worked rather well for my meagre requirements.

I haven't compared ASIO vs WASAPI for any of my audio midi devices.

[BJG145]

It is useful. But I'm not going to apologise.

[Lostgallifreyan]

In case anyone's still interested, I have some news... James Perrett (and Johnsy) were right to urge me to persist with ASIO. The hostsample is as impenetrable as ten consecutive Notpron riddles, but once it's re-written to output a static DC offset (so we can see what channels are in use on VU meters on the hardware's console software) it is easier to reduce to emulating a stereo pair, and seeing what the minimum data structure is, for supporting that, or some arbitrary channel count. I think Steinberg made that sample more complex than it needed to be. A simpler sample, with added code to enumerate existing drivers and ports would have been nice, I had to do all that myself, using clues that were in the core ASIO files but not documented as plain test anywhere, let alone in the manual, or the host sample.

I now have a (crude) ASIO DLL compiled as C++ (by Microsoft's compiler, or by G++), dynamically linked and loaded by a C program (compiled by GCC with strong optimisation) which is currently generating a sine wave at 440 Hz and filling the ASIO buffers. There is no loss of performance as compared to having that generator inside a single ASIO executable test program.

All I need to do now, having figured out how to make a callback from DLL to EXE and other means to share data and call code, is to determine what functions to export. Something similar to the list of exports from Native Instruments' NIASIO.dll seems to be a good guide. My DLL is almost exactly the same size as theirs, so it looks like I managed to reinvent their wheel...

I may go on to consider some static link to object files, but this DLL method is cleaner, less complex, and puts no restriction on connecting another coding language with the C++ dll. If it goes wrong it's independently fixable. It's a better method for multiple synths too. One DLL to rule them all, one DLL to bind them....

[NativeDev]

https://github.com/3rdGen-Media/PbAudio ... asio_ext.c

[Lostgallifreyan]

https://github.com/3rdGen-Media/PbAudio ... asio_ext.c

I solved mine as described before, but I refined it a bit. It works well, because I figured out another way to pass data between DLL (compiled as C++ with MSVC, the way Steinberg prefer it), and my EXE (which is C, compiled by GCC). That way I didn't need to use the stack, or worry about mismatched DLL function calling conventions, name-mangled exports, etc. Using return values is safe, so I can always get an answer from one process when called for by the other. The DLL is dynamically loaded in the main process memory space so it stays solid.

What you posted might help someone though, it seems to take care of driver enumeration, getting port names, etc, and the Steinberg ASIO hostsample.cpp file was not helpful with that, it takes some burrowing into the main ASIO host core files to figure out what to get at, and how and when to get at it.

Another thing that neither that example, or the original host sample, helps with easily, is getting just one pair in, and one out, which is useful because a card like Echo Layla will allow my BlueStar synth to use 2 ASIO outputs while any other port pair can be used, so long as it's not by ASIO. Whether this limitation is driver-specific in Echo Audio's driver, or by something I missed in the host sample code, I don't know, but it does at least allow programs some cooperative use of multichannel I/O at same time.