Portaudio

[steve]

Hi,

I have a problem that only occurs when ASIO4ALL is installed.

When using a Portaudio application (ww.portaudio.com), the MME or Direct Sound drivers for the internal AC97 do not work. If I open then close the ASIO4ALL driver in the same application, the MME and Direct Sound drivers start to work.

I thought I'd test the waters before I start submitting errors and code. This happens on 3 different machines.

Versions:

Portaudio: V19
ASIO4ALL: V2.1
Platform: Win XP
DirectX: V9

I have "fixed" the problem by scanning for the ASIO4ALL driver and doing an open -> close on it at startup after portaudio initialisation. The application then runs fine. I am guessing at this stage that something in Portaudio or ASIO4ALL is not being de-allocated after enumeration.

Any ideas?

Steve

[Michael Tippach]

Hello Steve,

This is a problem with Portaudio that, in a similar fashion, I have encountered in the past.

What happens is that PA not only loads ASIO4ALL, but also calls ASIOinit(), which would make A4A claim access to the audio device(s) selected in the control panel (quite rightly so). This is by design, in order to prevent any system component, such as the dreaded MS GS Software Wavetable Synth from being initialized and screwing things up.

The audio device(s) will not be released until ASIOstop() is called or ASIO4ALL is being unloaded, but it is exactly this bad practice of PA - to not do that but rather open just about anything it finds in the system and _leave_it_open_ - which is causing these glitches. This sometimes can backfire the other way around, disallowing ASIO4ALL access to a device merely because the MME/DirectSound driver has been left open without being in actual use.

They definitely should fix this.

[sebATplogue]

Hi there,

I'm looking at this because we experience the problem
in Bidule.

All calls for ASIOInit are matched by ASIOExit calls (in the latest tar ball but I suppose it has been so for a while)

If I add ASIOStop calls before all ASIOExit calls, the problem
doesn't occur anymore but ASIOStart is never called
during the scanning process so I don't think this
is good practice.

Shouldn't the clean up code occurs on ASIOExit instead of ASIOStop ?

[Michael Tippach]

ASIOstop() is safe to call at any time with ASIO4ALL but it might not be with other ASIO drivers, so it is not good practice indeed.

The problem with ASIOexit() is that it is not an actual part of the ASIO interface definition. In the Steinberg SDK, ASIOexit merely calls Release() on the COM instance.

I am currently running some tests in order to see whether de-initializing the driver at Refcount=0 has any negative impact (well, it _should_ not...)

If it turns out there are no problems, I will make this a permanent change in the STB next release.

[steve]

Hi,

V2.2 seems to have fixed the problem. Cool!

Thanks for the quick reponse.

Steve