When my AudioAppComponent is starting up, prepareToPlay is called three times. I know why this is, it is because you must call setAudioChannels to properly initialize, which calls prepareToPlay. Then, in my case, I am setting the device type (setCurrentAudioDeviceType) to ASIO - which calls prepareToPlay. Finally, I set my actual device up (initialize OR setAudioDeviceSetup both exhibit the same behavior) - which calls prepareToPlay.
I am doing enough setting up in prepareToPlay that this adds 4 seconds to my startup time.
I have worked around this by creating a boolean to indicate when I’m ready to actually execute prepareToPlay, but this is a pretty ugly hack. Am I doing something wrong? Is there a better way to choose an ASIO device in an AudioAppComponent?
I think you can avoid this by setting the options already in an xml and add it to setAudioChannels call.
To figure out the xml, have a look at the sources:
Mind, that prepareToPlay will freeze your app, so 4 seconds is really borderline IMHO. If there are things that take so long, maybe you can put them in extra threads? I think there are issues with your architecture, but I cannot know your requirements…
Yes, you cannot do that. Especially when you change the device type between the calls, you will get different arguments, that should be addressed in your initialisation.
Instead, if e.g. allocating a buffer, I would check, if it has already the requested size and so on (but then, AudioBuffer does this check anyway…), so that sounds odd to me.
Maybe you can share the code in prepareToPlay, so we might spot ways to improve?
Ah, sorry, I failed to mention that the XML options also exhibit the same issues - it has something to do with changing the type of device to ASIO. I get fewer calls to prepareToPlay when using other device types.
I am deciding which device to use based on which devices are attached, so this option is of limited value anyway.
Sorry, I think you misunderstand. It’s the redundancy which adds 4 seconds to the startup, the startup without the redundancy is only about a second. For what it’s worth, the audio is only initialized at the startup and never again, so the application does not freeze later. It’s not an incredible cost, as the startup is still faster than a lot of similar applications.
The only settings that matter to me at all are the very last settings as I would literally throw away any setup performed earlier in the process - this method works for me, I just don’t like it because I am having to keep track of initialization state in a way that is not elegant.
I am sorry that I can’t share the code - the application is very large and complex, that’s why prepareToPlay can add 4 seconds to the startup when run 4 times instead of 1. prepareToPlay calls several objects representing different parts of the application that are responsible for initializing DSPs, VSTs, convolutions, high-order polynomials, etc. It’s not a small collection of code. Most of these things need to know the output frequency to be calculated properly, so it’s not something that I can initialize in parallel and the application can not do anything until this initalization is done.
What I have works… I was just looking to see if there was a better way to defer calling prepareToPlay than what I am doing. It sounds like there may not be.
