I’m starting to do some audio work on my macmini with JUCE, but I’m getting the above message on the run log/console when I construct an AudioIODevice object (as well as a couple of times later, when I try to use some of its methods). I’m just constructing it like this at the moment:
StringArray tempArr = AudioIODevice::getDeviceNames();
soundcard = new AudioIODevice(tempArr[0]);
When I run the debugger, it gets caught at the jassert at line 516 of juce_string.cpp. Further up, it seems to be line 379 of juce_mac_coreAudio.cpp that’s causing the problems, although I don’t know why :?:.
This is just with the mini’s internal soundcard, btw. I assume I’m constructing the AudioIODevice correctly - is this a bug, or am I doing something stupid?
i is 0, so it’s 44100.0 - I can’t imagine why it would cause problems though. Could it be a symptom of another problem maybe? Perhaps to do with the fact that the mini only has a stereo output, and no input? I should maybe try plugging my m-audio firewire thing in, to see if it’s specific to the mini’s onboard sound.
It doesn’t sound like an audio problem - more like memory corruption or something. If you run the demo app and go to the audio page, does it also assert?
Yes - I thought at first it might be something to do with my XCode project settings (since I’m using v1.5, and had to convert the project file to jucedemo.xcode), but even the pre-compiled binary from your site is giving me the ‘Debugger() was called’ messages on the command line.
You could try catching it just before it calls the string function, and trace into String::doubleToStringWithDecPlaces()… to see what it does, and what the ‘len’ value ends up as when it asserts.
It’s very strange - I can’t see anything wrong with the code, and it’s fine on my mac…
len is set to 0 when it asserts. Could there be something up with the call to juce_sprintf? The contents of buffer after it’s been called look correct though :?.
Okay, having done some investigating, it looks like swprintf can’t handle a buffer size greater than 24 on my system for some reason :?. It works fine when the size is less than or equal to 24 - it sounds like a bug in swprintf to me…
Will I run into problems if I just make bufSize 24 instead of 80? That seems the simplest solution, though I don’t know if it’ll cause problems further down the line?
Actually, no - ignore that. Testing it again, even that doesn’t seem to be working any more. I’ve no idea what’s going on. juce_sprintf/swprintf seems determined to report an error.
Stepping through in the debugger, it does sometimes returns the correct value, but not always… I think I need to do some more investigating :?.
Having added in a couple of lines to output to the command line what’s hopefully relevant information, I get the following:
[code][Session started at 2005-10-03 19:33:42 +0100.]
Built-in Audio
len = 0 buffer = 44100
Debugger() was called!
len = 6 buffer = 48000
len = 0 buffer = 88200
Debugger() was called!
len = 0 buffer = 96000
Debugger() was called!
CoreAudio error: 399 - 77686f3f
Debugger() was called!
CoreAudio error: 402 - 2173697a
Debugger() was called!
len = 0 buffer = 44100
Debugger() was called!
len = 6 buffer = 44100
len = 6 buffer = 48000
len = 6 buffer = 88200
len = 6 buffer = 96000
Executable “PhantomPower” has exited with status 0.[/code]
len = … buffer = … is the values after line 508 (? - I added in a header, so that might not be it exactly, it’s the len = juce_sprintf() line). The CoreAudio thing is another thing I noticed happening. Is this at all useful? I’ve no idea why the juce_sprintf call would sometimes work and sometimes not with the exact same text…
Unless there’s some memory getting corrupted somewhere, I just can’t think why printf would behave unpredictably.
The errors you’re getting are just where it fails to get the latency, the 399 and 402 are line-numbers in juce_mac_CoreAudio.cpp where it caught the error. So not relevant to the bug, I think.
Okay, well I’ll just assume it’s something specific to my system, seeing how the demo app shows the same symptoms but seems to work fine for you. Hopefully it won’t cause problems further down the line…
It’s a worry, but I can’t think of anything else to suggest at the moment.
Could be a bug in the mac mini audio drivers, I suppose, which overwrites a bit of the stack, though it seems unlikely.
If I was debugging it here, I guess I’d try moving stuff around in the updateDetailsFromDevice() method to see if I could get it to stop happening, and then figure out what it was that made the difference. Could also try scattering in some extra lines doing things like “rates << 44100.0” to see if printf fails in other places in the method, or whether it only fails after a certain point.
Ok, I’ve had this happen to me too - or something similar. There’s a bug in the String method that fails to handle NAN or INF values, and some stuff in CoreAudio that needs to handle errors better. I’ll be posting a fixed version within a few days…
