I have a customer that complains that my Juce based application can’t playback audio and I ended up sending him the Juce demo. It seems that with the demo he can only play aif files, but no wav files. It just sits there and does nothing. This is on more then one Mac, all G4 and G5, OS 10.4.11. The executable I send him works fine on my G4 and MacBook Pro.
Any ideas?
It sounds like an endianness bug, but if it works on your G4, that can’t be it.
Maybe he’s using wacky wav files that are encoded with an unusual format? I’d suggest asking him to send you an example of a file that doesn’t work and try it yourself.
I did, just a normal 16/44 file. Could there be some library be missing? The executable I send him was compiled on my MacBook Pro with the 10.5 SDK.
No, none of the wav code relies on libraries, and shouldn’t be affected by the OS version at all… I’m really stuck for ideas on what to suggest!
I suppose you could hack the demo so that it logs plenty of info about how far it gets trying to open the files, and send that for him to try.
Which version of Juce is this, BTW?
don’t know the version number, but I updated to the tip at December 9th
It’s certainly an odd problem.
I have send him a demo with this altered function in it:
[code]void AudioDemoPlaybackPage::loadFileIntoTransport (const File& audioFile)
{
// unload the previous file source and delete it…
transportSource.stop();
transportSource.setSource (0);
deleteAndZero (currentAudioFileSource);
// get a format manager and set it up with the basic types (wav and aiff).
AudioFormatManager formatManager;
formatManager.registerBasicFormats();
AlertWindow::showMessageBox (AlertWindow::WarningIcon,
T("Debug info"),
T("Known formats:") + formatManager.getWildcardForAllFormats());
AudioFormatReader* reader = formatManager.createReaderFor (audioFile);
if (reader != 0)
{
currentAudioFileSource = new AudioFormatReaderSource (reader, true);
if (currentAudioFileSource == 0)
{
AlertWindow::showMessageBox (AlertWindow::WarningIcon,
T("Debug info"),
T("error code #2"));
}
// ..and plug it into our transport source
transportSource.setSource (currentAudioFileSource,
32768, // tells it to buffer this many samples ahead
reader->sampleRate);
}
else
{
AlertWindow::showMessageBox (AlertWindow::WarningIcon,
T("Debug info"),
T("error code #1"));
}
}
[/code]
No problems seen, *.wav showed up as a known format, just no play for a wav file! The waveform is also not drawn, so it seems it can’t open or read the file. However, formatManager.createReaderFor () was successful, so it did open the file, didn’t it? Any suggestions I can try?
Very very odd. What I really meant, (and should probably have explained better) was that you could scatter some debug info in the WavAudioFormatReader constructor, so you get some low-level info about which wav chunks it was finding, and what values, if any, it was getting for file length, sample rate, etc. Also, it’d be worth putting some logging in WavAudioFormatReader::readSamples, to see whether it’s failing to read any samples, or whether it’s failing to convert them to meaningful values.
But it really is strange - the wav code is rock-solid, has been used for years in lots of different apps, on big and little endian machines, and I’d be very surprised to find a bug in it!
ok, I will do that. I think it is very odd too, and if it was just one machine, fine, but this man claims that it does not work on all his machines…
The exact wav file he uses plays fine on my Macs. I’ll keep you posted.
After successfully trying the official juce demo on your website, I managed to get him a build that worked. I seems that I need to compile against the 10.4 SDK to get it working on his side. The original version was compiled against 10.5 and that did not work.
Can you make anything out of this?
That doesn’t make sense - all the code in the wav file classes is pure c++, there’s no platform-dependent code at all! Just having a quick look, there’s nothing at all I can see that could go wrong. The only native call it makes is an old OS call to swap the byte order, but that’s not going to fail.
If you were compiling with the 10.5 SDK, then you had set the 10.4 compatibility flag, right? That’s Apple’s preferred way to build for old platforms, so should work!
what flag do you mean?
I have set the Base SDK to 10.5 and the Deployment Target to 10.4
[quote=“PieterS”]what flag do you mean?
I have set the Base SDK to 10.5 and the Deployment Target to 10.4[/quote]
Yes, that’s what I meant.
I’m really stumped. I guess there it could be using some kind of API call that’s missing in 10.4, but I’d expect that to just crash the whole thing - the fact that only the wav reader is failing is baffling! Even if there was a bug in 10.4, I just don’t know where it could be to affect this.
Well, at least we know what the problem is, or in what direction… The solution is a bit harder I guess.
I am hesitating to release my software build against the 10.4 SDK. It seems the only thing I can do is to officially support version 10.5 and above, not an ideal situation.
Maybe there is something missing on his system, I don’t know.
Thanks for your help.
Would love to get to the bottom of it, but not sure what to suggest…
It shouldn’t be a problem if you build your application with 10.4 SDK. We build our application on Tiger using 10.4 sdk. We haven’t had any issues yet.
Another solution would be to have two applications(installer), one built with 10.4 SDK and another with 10.5 or higher.
The problem is weird, If you set deployment target as 10.4, your application should work without any issues. Did you build juce with Deployment target as 10.4 too?
I use the amalgamated version so it is compiled the same as my source I guess.
Are you using any other dylib/lib in your application. Does this problem occur on power pc machines running Leopard ? Or strangely, could it be that the application works fine on the SDK in which it is built ?
If you are not using any other lib the best option would be to have a separate installer(binaries) for tiger and leopard/snow leopard.Till the problem is fixed.
You wouldn’t be the first person to do it. Fink also releases separate binaries.
I only heard of problems with ppc/10.4. That particular person also has problems with the Juce demo when built against 10.5.
My application uses other libs, but it builds fine with 10.4, so I go with that.
It’s a weird problem. Go with what works.
