use OGG sounds not saved to disk?

I’ve made some more tests. It’s not about the file size/audio length. I managed to play some <0.5 second long oggs which I made myself.
They all have the same codec settings: 128 kbps, 44100 Hz, stereo; or 80 kbps, 44100 Hz, mono. That doesn’t seem to be the problem too.
Also, for some files OpenAL seems to skip the error message, although it doesn’t play the sound too, FMOD always displays the error message.
This is beyond me.

When I try these two sound files in my own personal build, they don’t play correctly in OpenAL, though they do sound OK in FMod. When I use the buildbot release, it doesn’t work in either platform. Probably I have a different version of FMod on my own build.

This has nothing to do with the ramdisk, though. It has exactly the same problem if you load the files directly from disk. It’s just some fundamental bug in (or incompatibility with) OpenAL and some version of FMod. My guess is it’s probably a bug in a particular version of the Vorbis decoder.

If it were me, I’d just convert these two small files to .wav format to avoid the problem.

David

You’re right, I don’t know what went wrong in my previous tests, sorry for the false alarm.

And do you get an error message with FMOD and nothing with OpenAL, like me?

It would be nice if someone could check if it’s indeed not a Panda bug, but an audio engine bug. It seems unlikely to me though that both audio engines have the same bug.

I wish I could, I’m not “allowed” to modify the game’s data archives.

Yes, I see the FMod errors on the buildbot version. Not in my personal build, though.

As I said, it plays correctly with the more recent version of FMod that I have in my personal build. I think this proves that it’s not a Panda bug. I don’t really know how it could be, anyway, since Panda doesn’t do anything with the individual sound file data, but just passes it unchanged to the underlying audio system.

It’s not too surprising to me that both sound libraries appear to manifest a similar bug. There’s really only one Vorbis decoder out there, and all of the sound libraries that support Vorbis use the same one. A bug in that decoder would appear in many different places.

Well, perhaps you can prevail upon rdb to upgrade the version of FMod that Panda is built with (or go build your own version of Panda with the latest FMod).

Other than that, I guess you’ll need to find some other workaround or hack if you need to play these files.

David

Well at least it’s good in the sense that the newer OpenAL might have it fixed too.

OK. I think he’ll notice this thread.

libvorbis has been at version 1.3.2 for a long time now. I just upgraded to the latest ffmpeg, but it is built against the same libvorbis.
I’ve just upgraded fmodex across the board to 4.34.15, which was released yesterday. Newer stable series remove several API features and don’t compile with Panda.

OpenALSoft was already at the latest stable on Windows.

Thanks.
You said you use the version of FMOD from yesterday, but then you say newer stable ones don’t work with Panda, do you mean version released today?

Also, I can’t find out when the latest OpenAL was released. Any ideas? I would like to know if it’s worth waiting for a new version from them or should I just get used to FMOD.

And are these updates only for Windows?

BTW, if it uses the same libvorbis, then probably the bug is in FMOD and OpenAL?

I installed a version of FMOD that was released yesterday, but on an older stable branch.

OpenALSoft 1.13 seems to have been released 9 months ago.

OpenAL has nothing do to with the decoding of audio, this is done by ffmpeg.

Hm, from what you said it’s ffmpeg which is causing the trouble and that latest Panda3d has the latest version. So how come the sounds play properly in drwr’s custom build? I’m confused.

No, rdb means that because OpenAL includes no code to decode vorbis (or any other sound file format), ffmpeg is used to decode the audio when you’re using the OpenAL library.

But when you’re using the FMod library, FMod is used to decode the audio.

David

Uhh, right, so… OpenAL uses ffmpeg, which uses libvorbis, and FMOD uses libvorbis directly?
In any case, buildbot Fri, 18 Nov 11 04:22:51 doesn’t seem to solve my issue.

I’m not sure that the buildbot release includes the latest fmod code yet. It looks like there have been some weird permissions errors preventing a successful build.

David

Yes, it seems the last 4 Windows build attempts have failed. Could it be caused by the fmod update?
That would explain it if FMOD is not available on other OSs.

Figured out the problem. Windows permission settings are weird! It was actually caused by a Pmw update I did a while ago, which hadn’t carried over into the build until I forced a clean build when I made the fmod changes.

Anyway, build is rolling. Sorry about the inconvenience.

I thought the Pmw package hasn’t been updated for few years.

Anyway, there might be another problem. THe buildbot still fails.

Yeah, but I found out that the Pmw version we used was still at 1.2 while the latest is 1.3.

Sorry about the buildbot. Fixed, a new build is on the website now.

OK. An unrelated question, why is Pmw in the root folder and not somewhere in python? Also, I don’t remember if it was like this before, but now the folder “Pmw” has two subfolders, “Pmw_1_2” and “Pmw_1_3”. Maybe the old one wasn’t removed properly?

As for the OGG issue, I’m afraid even the new buildbot doesn’t solve it (I did make sure I’m running FMOD).
drwr, what version of FMOD does your custom build use? Since you said you could play those files.

Bumping the thread.
drwr, can you please tell which version of FMOD your custom build uses?

My fmod.h lists a version number of “0x00042205”. But now I suspect it may not be strictly a version issue. Perhaps there’s something more subtle going on here.

David

Any ideas man?
I have none.
It doesn’t seem to be an issue with file size which I thought previously, or codec settings, which I tested a bit later.
Do you think it has anything to do with vorbis library then?