audioDeviceManger and Xml-file ...and bonus question :)

[heureka]

Hi

I’m not a skilled C/c++ programmer so please bare over with me with this simple question:

I have a problem with the audioDeviceManager() which I’m trying to configure using a saved Xml-file containing the soundcard configuration from the previous run of my program.

Here is what I do in the constructor:

[b]// Setup Audio throughput
XmlDocument myXmlDocument (File(“c:/audioManagerState.xml”));
XmlElement* k = myXmlDocument.getDocumentElement();

if (k == 0)
{ String error = myXmlDocument.getLastParseError();
myAudioDeviceManager.initialise(2,2,0,true);
}
else
{
myAudioDeviceManager.initialise(2,2,k,true);
}
delete k;
myAudioDeviceManager.setAudioCallback(this);

[/b]

and here is what I do when pressing the button that opens the dialog window for soundcard configuration:

[b]// Create an AudioDeviceSelectorComponent which contains the audio choice widgets…
AudioDeviceSelectorComponent audioSettingsComp( myAudioDeviceManager, 2, 2, 2, 2, true, false, true, false);

// …and show it in a DialogWindow…
audioSettingsComp.setSize (400, 600);

DialogWindow::showModalDialog (T(“Audio Settings”),
&audioSettingsComp,
this,
Colours::azure,
true);

XmlElement *k = myAudioDeviceManager.createStateXml();
if (k != 0)
k->writeToFile(File(“c:/audioManagerState.xml”),"");
delete k;
myAudioDeviceManager.setAudioCallback(this);

[/b]

I think this should work OK but my program breaks when I later do FFTs (fast-fourier-transforms) using the FFTW-library. I think the problem is that the XmlFile is not closed/released before addressing the FFTW.dll file. Can someone please tell me how I should do this properly?

Also, when the program breaks I’m not able to recompile. Visual Express prompts:

1>LINK : fatal error LNK1168: cannot open .\Debug/juce_application.exe for writing

…and I have to reboot my computer to be able to compile. Anyone knows how I can avoid rebooting?

Best Regards
Thomas

[atom]

first question dunno

second question, the EXE is running in the background and the linker can’t write to that same EXE file, open your TaskManager and kill the running juce EXE application by force, the linker should re-compile with no errors.

[heureka]

[quote=“atom”]first question dunno

second question, the EXE is running in the background and the linker can’t write to that same EXE file, open your TaskManager and kill the running juce EXE application by force, the linker should re-compile with no errors.[/quote]

Thanks for your reply!

I’ve tried to kill the JUCE-application in the taskManager but it doesn’t close down

[atom]

that usually means there is something wrong with your audio driver handling stuff, witch may be the case looking at your first question, deal with that and the application should never hang.

can you say what exactly breaks? did you try debugging the app ?

[heureka]

[quote=“atom”]that usually means there is something wrong with your audio driver handling stuff, witch may be the case looking at your first question, deal with that and the application should never hang.

can you say what exactly breaks? did you try debugging the app ?[/quote]

MY debugger breaks when doing the FFTW transform:

That’s all I get!

The FFTW uses a DLL so another file is adressed (than the XmlFile for the soundcard configuration). I think that is my problem…somehow the XmlFile is not “released” after reading from it. I mean, I remember that when you want to write data to a file you have to close the file when you are done ( fclose() ) before reading from another file…I could be wrong though!

Thanks for asking!

[atom]

i really don’t think that the Xml has anything to do with the error your getting from FFTW, the XML file holds the data on the soundcard, how many channels sample rate and so on.

the FFTW and the XML file are not connected, if you have a problem with fftw you should look into that, the XML handling you wrote looks OK.

[heureka]

[quote=“atom”]i really don’t think that the Xml has anything to do with the error your getting from FFTW, the XML file holds the data on the soundcard, how many channels sample rate and so on.

the FFTW and the XML file are not connected, if you have a problem with fftw you should look into that, the XML handling you wrote looks OK.[/quote]

The program runs smoothly (providing true FFT output) when I’m not saving or loading the configutation-XML file for the audioDeviceManager. It must have something to do with file-handling…I’m not blaming JUCE!

Thanks
Thomas

[valley]

are you sure you’re not corrupting the heap somewhere? The XML is most likely a red herring, but if as a side effect of that operation, you’re writing over some memory that is in use by the audio driver, you’ll run into trouble.

[heureka]

@valley

are you sure you’re not corrupting the heap somewhere? The XML is most likely a red herring, but if as a side effect of that operation, you’re writing over some memory that is in use by the audio driver, you’ll run into trouble.

Hi

The audioDeviceManager XML part works well when I don’t do the FFTW transformation. I think the problem is that the FFTW call is done in the audioDeviceCallback thread and while this goes on and I press the soundcard config button two files are adressed at the same time.

I just tried to stop the audioCallback before writing the XML data but that didn’t slve the problem, I tried:

myAudioDeviceManager.setAudioCallBack(0);

So I gues the question is: how do I ensure that the FFTW call is not done when I write the XML-file?

Hope I’m making sense here

Thanks for keeping up
Thomas

[valley]

It sounds like you need to use a critical section, or a suitable lightweight alternative.

If your hope is for real time performance, then generally critical sections are to be avoided. If that’s not such a concern though, and you don’t have control over the FFT code, then it’s something you might want to consider.

If time critical performance is required, you’ll probably need to buffer the data such that the audio thread has its own private copy of the audio state. You could then do a buffer switch or some such to allow for a fast update when the audio thread is idle. This is all a lot more effort than using critical sections though, so there’s your tradeoff.

[atom]

my idea is to load the contents of the XML file on startup (ctor of your app) and use that chunk of memory instead of loading files, this will be faster, in the dtor of your app just update the XML and write it to disk.

[heureka]

@atom

my idea is to load the contents of the XML file on startup (ctor of your app) and use that chunk of memory instead of loading files, this will be faster, in the dtor of your app just update the XML and write it to disk.

Thanks for the advice…that sounds like a good solution. I will try that tomorrow morning!

again thanks!

Thomas

[heureka]

@heureka

[quote=“atom”]my idea is to load the contents of the XML file on startup (ctor of your app) and use that chunk of memory instead of loading files, this will be faster, in the dtor of your app just update the XML and write it to disk.

Thanks for the advice…that sounds like a good solution. I will try that tomorrow morning!

again thanks!

Thomas :)[/quote]

After saving the the XmlData in the destructor of my main class of I now find that only the constructor part causes trouble.

XmlDocument myXmlDocument(File("c:/audioManagerState.xml"));
XmlElement* k = myXmlDocument.getDocumentElement();
if (k == 0)
{	String error = myXmlDocument.getLastParseError();
	myAudioDeviceManager.initialise(2,2,0,true);	 
}
else
{
	myAudioDeviceManager.initialise(2,2,k,true);
}
delete k;
myAudioDeviceManager.setAudioCallback(this);

…and I still can’t recompile the program when it halts without having to reboot first

Visual Express states that is can be due to corruption of the heap. I don’t know what this means …will have to google information on this!

Damnit