Filechooser causes drop outs

My project is a live mixer that is currently running very well with very low latency. However, anytime the gui does a filechooser, I will get some dropouts. Example: click file->save as, I get a number of dropouts. I have and integrated player, and recorder, both of which use the file chooser that cause the same problem.

Example code: save as from the menu calls this code in the maincontentcomponent:
FileChooser myChooser (“Please select file to load/store mix…”,
File::getSpecialLocation (File::userApplicationDataDirectory ), “*.mix”);
if (myChooser.browseForFileToOpen())
File mixFile (myChooser.getResult());
if (mixFile.getFileExtension() != “.mix”)
String fn = mixFile.getFullPathName() + “.mix”;
I dont see how this can interfere with the audio threads. Anyone know?
(how should I post code snippets so they are formated?)

I don’t think this is a common problem, so posting your file chooser code isn’t likely to produce any answers. the code to look at would be your audio thread.

The interesting thing is that the dropouts occur simply in opening the chooser dialog. The selection to save or cancel the ‘save as’ does not cause the problem., simple opening the dialog.

I use a thread pool for doing all the audio processing (except the asio callback which simply does addjobs to the theadpool).

What I don’t understand is what the filechooser does to cause high latency. I’m running on a 6 core (12 thread)processor and audio is only using 4. So how does the gui thread interfere with the audio threads(my thread pool or the asio thread).

I’m just hoping someone has seen this and can tell me what they did wrong cause I probably did the same thing. Doesn’t hurt to ask.

I have seen the same issue but only in debug build under VS.

It is worse with VS in debug. I am running release without VS and I see this. I am pushing it. Running asio buffer size 32. The larger the buffer, the less I get it.

Mu software measuring callback time and when I do a save as, then cancel, I get 39 late callbacks with the slowest being 15.7 ms. If it delayed even 1ms it is too much.

Another interesting thing, if I do it a second time it does not happen. I assume it is reading the filesystem, but is cached so the second time it does not happen.

Oh my, I remember seeing the exact same thing a few years ago, only I was using a FileBrowserComponent. Never got around it…

You can use the performance monitor tool in windows to check if there is any CPU usage changes while opening a file chooser.