Recommended Posts

I've a problem, I wanted to get Ogg Vorbis support in my engine but i'm having troubles getting the libraries working. It seems that Xiph.org no longer provide the libraries, instead they only provide the source code and some .bat files to generate the .DLL's .lib's, etc. but there are no instructions on how to generate them. Executing the .bat isn't enough, for example, to generate the vorbis libraries I must copy the Ogg headers to the Vorbis include folder(very messy).
When I run the .bat files, the compiler (I don't know which compiler uses) gives a lot of warnings about data type conversions that may generate loss of data precision but yet it still finishes the compilation process and I get the libraries.
Now that I have the libraries installed, they are giving me problemas because this simple code:
OggVorbis_File vorbisFile;
vorbis_info *vorbisInfo;
ov_fopen((char*)soundFileName.getString(), &vorbisFile);
vorbisInfo= ov_info(&vorbisFile, -1);
unsigned int bufferSize= vorbisInfo->channels*2*(unsigned int)ov_pcm_total(&vorbisFile, -1);
is causing the engine to crash, the VC++ 2005 compiler reports a "buffer overrun". I've done some experimenting and seems like its the ov_pcm_total function that is causing that error.
I have no ideia what is causing this problem. Is it my code? Is it the libraries? Are those data precision loss problems causing problems in the libraries?

0

Share this post

Link to post

Share on other sites

I was having issues that sound really similar to what you are getting. Look at this diff to see what I did to fix it. If I remember right, basically the ogg libs are being compiled with a different C std library than you are using (e.g. not multithreaded) and that causes the crash. If you use the callbacks, it uses the functions you pass in rather than the ones from the C std lib it was compiled with. Post back with whether that helps or not. I'm sorry, I'm in a rush now, I'll try to explain more a little later or maybe someone else can chime in...

Share this post

Link to post

Share on other sites

Again, if you are having the same issue that I was having, then you have actually compiled the libs just fine. I used the Visual Studio solutions that are included in the ogg/vorbis code. They are funny because they expect the libs to be in particular places, but they seemed to work.

You could be having a different issue, though. Can you post the exact error you are getting? Also, try googling your exact error. That was how I found my solution.

Edit: Based on what you are doing, it looks like a different issue. Sorry, should have looked at your code more closely. According to the ov_pcm_total() docs, it can return OV_EINVAL in some cases. Are you sure that ov_pcm_total is returning a valid value?

0

Share this post

Link to post

Share on other sites

I've been experimenting a little more and following some of the ideias you guys gave me but and I can't solve the problem. What I found is that whenever I open the file through ov_open, ov_fopen or ov_open_callbacks I get the error "Run-Time Check Failure #2 - Stack around the variable 'vorbisFile' was corrupted.".

As far as I could find out, that error means that an ilegal memory access is happening on the vorbisFile variable but I'm not doing any memory access, only the oggVorbis library is doing.

The callback functions I created are just wrappers to the ANSI file functions and seem to be correctly defined.Both fopen and ov_open_callbacks return success codes, but when the method CSoundSource::loadSound returns, the error shows up. If I comment the line that calls ov_open_callbacks the error doesn't show up. As I said before, it seems that the ogg/vorbis libraries are messing up the data inside the vorbisFile variable.

Does anyone have a clue about this? Perhaps I have a problem in my libraries, could some one give me libraries that I can use to test?

Share this post

Link to post

Share on other sites

"Both fopen and ov_open_callbacks return success codes, but when the method CSoundSource::loadSound returns"

Ok, first: tell me that the Vorbisfile struct isn't actually declared inside the loadsound() function. Because if it is, then it will be destroyed by C++ once the function returns. Maybe you just added it for clarity... but I need to check :)

0

Share this post

Link to post

Share on other sites

Yes, I declared the struct inside the method. When I read your question I remembered to try to declare the struct outside the method and now I can load and play sounds. But the problem still appears when my application closes, it seems that the problem is generated when the variable is destroyed, by declaring it outside the method I only delayed it's destruction until the program termination.

So now the question is why the hell does that error show up when the variable is destroyed?

0

Share this post

Link to post

Share on other sites

I found what the problem is, but I don't know how to solve it. By doing some experiments on the ogg/Vorbis source code I found that the size of the OggVorbis_File struct is different in the libraries and in my code, the libraries use a structure with a length of 720 bytes, while my code uses 702 bytes. I found this simply by adding, in one of the libraries, a line of code that prints the value of sizeof(OggVorbis_File) and then making the same thing on my code, and as I said the results were different.

I've also tried to compile the libraries using the VC++ 2005 projects that come with the libraries source code, but when I build them I get some missing external symbol errors.

Does anyone have a clue about what I can do to solve this problem?

0

Share this post

Link to post

Share on other sites

Problem solved, the difference of the OggVorbis_File structure size was caused by a configuration on VC++ 2005. The "structure memeber alignment" field should be set to "default" but sometime ago,and for some reason I don't recall, I set it to 1 byte. Now everything is working just fine.

Although the tips you guys posted here were not the answer to my problem, they gave me clues that helped me finding the solution. Thanks for the help!

---João Cabeleira

0

Share this post

Link to post

Share on other sites

This topic is 3735 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.