Slow load after ASIO build (Windows 7)

[ctrezza]

I just finished building Audacity (unicode Release 32-bit) so I could use the ASIO drivers in the app on my new 64bit Windows 7 box. I noticed that it
is loading a lot slower than the release executable from 1.2.6 (release build, not mine) and was wondering if anyone knew what was making the program load dog slow (over a minute) - could it be something on the ASIO side (my guess) or perhaps a flag I missed? I used Microsoft 2008 VC++ for the build, wxWidgets 2.8.11, taglib 1.6.3; I gave up on cygwin and MSVC++ 2010.

In other news I edited AudioIO.cpp to use DefaultProjectSampleRate instead of the highestSampleRate in HandleDeviceChange() in my build . My EMU soundcard uses Patchmix and every time the application asked for the maximum I'd have to reload the settings in Patchmix only to have to reload them again a few seconds later when the app set things back to the project default rate. It only happens on the initial load, but if you don't set things in exactly the right order the app crashes (e.g. the app calls for 192000, you update patchmix and then click Monitor Input and then set patchmix to the project rate, the program will likely crash.) I'm not sure what the original intent was initializing with the max rate, but for anyone using Audacity with Patchmix, the modest code change below is a sanity saving measure:

// rather than set the playback format to the max value, set it to the project value
// right before the first Pa_OpenStream call in HandleDeviceChange() (File: AudioIO.cpp)
int defaultSampleRate;
gPrefs->Read(wxT("/SamplingRate/DefaultProjectSampleRate"),
&defaultSampleRate, GetOptimalSupportedSampleRate());

and changing the 3 Pa_OpenStream calls to use defaultSampleRate instead of highestSampleRate, e.g:

error = Pa_OpenStream(&stream,
&captureParameters, &playbackParameters,
defaultSampleRate, paFramesPerBufferUnspecified,
paClipOff | paDitherOff,
audacityAudioCallback, NULL);

Also, I'd like to say thank you to Gale and all the other folks who work on Audacity. You are awesome!

[steve]

One possibility may be that Audacity is having trouble scanning for VST effects.
Try (temporarily) disabling VST support (Edit menu > Preferences > Effects) and see if Audacity loads quicker.

[ctrezza]

Thanks for replying. I did try that and no luck. The program is slow before the first call to HandleDeviceChange() and when I had compiled in debug mode
there were a number of threads exiting sequentially to that point, and those seemed to take a relatively long time with each. For kicks I went back and changed the ASIO drivers in the preferences to MME and hey, the slow load is gone! So I think that it's ASIO related, I just don't know where or why - it could be in AudioIO, or the portmixer, or the SDK.... or just my machine has some funny business somewhere...

[steve]

I know that it's asking the obvious, but just in case it's been overlooked - I presume that you have ASIO drivers installed for your sound card and you have tested that they work correctly?

[ctrezza]

It *could* be something with the drivers themselves. I'm using ASIO drivers and they do 'work', I can play, I can record, but they ARE beta drivers. I have an EMU 1616m pcie, and the latest, best drivers for windows 7 64bit are beta drivers. I've de-installed and reinstalled them in the hopes that would fix the problem, but alas, no. I may try ASIO4ALL to see if that works. At this point I'm happy that they work at all, with all the trouble I've had getting my audio setup back to where it was with XP. I've got new hardware, a new OS, a new soundcard, and I'm still trying to figure out how to get everything done. Anyway, I'll keep poking around with it. Thanks for your help!

[ctrezza]

Okay, so I narrowed the problem down to a single line in asiolist.cpp:

LONG AsioDriverList::asioCloseDriver (int drvID)
...
iasio->Release(); // this is the really slow call, it takes a
// second at least on my machine. Lord knows why.

...

Apparently, during initialization, we call ASIOInit()/ASIOExit() in pairs
while we figure out every possible playback, sample rate, and capture rate for the device.
The driver loads and unloads over and over. On my box it takes forever because each Release()
call takes a second or more. I'm not sure why that's necessary. The spec - I've got 2.2 -
doesn't suggest you need to unload at all until you're done - you just need to accept a callback in case it needs to reload.
We could probably do it once for initialization. Is there a rationale for unloading it so many times?

Thanks!

[Gale Andrews]

Hi ctrezza

I'm not actually a C++ programmer but first off I'll try and build SVN with ASIO support and verify the slow load problem exists on another machine with different hardware. Give me a while though. I only have Realtek built in sound device and a cheap USB sound card so I would try it with ASIO4ALL. If the slow load exists there I'll raise a bug and add your input.

The issue with not initialising to the default sample rate has been noticed before by people using their own ASIO-enabled Audacity build, for example:

There seems to be a problem with the initial setup of the asio connection. Lets say I have the Motu set at 44.1khz... When I enter Audacity 1.3.8b, Audacity seems to initialize the ASIO connection and changes the MOTU rate to 192khz (Even though the project rate is clearly listed as 44.1khz at the bottom of the screen. When I hit record, indeed it does record at 192Khz, even though it marks the track as recorded at 44.1Khz.

When I hit "stop" on this first recording track, Audicity will reset the motu to the correct rate (44.1khz) and from there on out, Audacity seams to work properly.

The same thing is true with playing tracks.. The very first track I play in audacity, the Motu thinks it is playing at 192Khz.... but then after I hit stop, Audacity will reset the motu to the proper rate (44.1Khz).

So this only seems to be a problem on startup of audacity... it always puts my motu device into this 192Khz mode...... then after recording or playing something (no matter how short), it seams to recover and start working properly.

However I'm not clear why this would be an ASIO only problem - isn't it just that high end sound devices like this would be using ASIO? In other words, is there the same problem when you choose MME? Again I'll have to raise a formal bug for this and add your suggested fix and let the signal processing devs decide if the fix is appropriate generally.

If adding the bugs doesn't seem to be exciting any interest, then you could consider subscribing to -devel list and offering your help. Or you could do that anyway... I think Vaughan has mostly been involved with ASIO work.

Thanks for your input.



Gale