Audio problems..

#21 Thread weaving:
This is an older thread that talks more about the specific problem that I'm seeing and I believe it's the same as other people here too

click here

I think I've cornered the problem a bit and found the final result but possibly not the cause. unlike previously stated I don't believe it's an OpenAL problem or a AC97 problem specifically, at least with what I've seen so far it looks like it has more to do with the ogg vorbis code here...but still not enough info to know either way.

#22 Ok, just got it to happen again, here's how I did it:
start game->load mission->walk arround->exit mission, but not game->start mission-> walk arround, had the sound problems.

I think I lucked out that it happened this first time, but I suspect if you just sit and do that over and over again it might show up.

another thing I'm doing that others possibly aren't is I'm using streaming ogg files. I have one stream that plays during the menu, and another that plays looping in the game as ambient background. Those sounds don't mess up, but perhaps there is some side effect there.

good news is I have a bit more info now that the problem happened again:
this shows some of the state when that impossible section of code runs:

Quote:
OggVorbisFile::_get_prev_page apparently the impossible is possible!
vf->offset = 7685
begin = 0
CHUNKSIZE = 8500
offset = 7685
ret = -2
og->header_len = 28
og->body_len = 15

another interesting thing is that it seems like it's always the same sounds...but I don't think it's _all_ the ogg sounds. hmm. perhaps they are just bad files? wouldn't that be nice :)

#23 Here's something interesting...
In my linker settings I was linking to both
../lib/vorbis/win32/ogg_static.lib
and
../lib/vorbis/win32/vorbis_static_mt.lib

that can't be right :) unfortunately it looks like VC knows enough to figure that out though, looking at the linker's command line only vorbis_static_mt.lib is used (which is correct for my projects)

edit: I take that back..it didn't show it because I had already removed it..smacks self.

#24 Ahh
ok I think I've done this before, removing that results in a bunch of link errors, ogg_static.lib is necessary
they are two different libraries.
neeeeevermiiiind.

#25

Quote:another interesting thing is that it seems like it's always the same sounds...but I don't think it's _all_ the ogg sounds. hmm. perhaps they are just bad files? wouldn't that be nice :)

Oh joyous day!

I think that it's just bad files.

I decoded the footstep_soft.ogg and reencoded it with the newer vorbis tools oggenc.exe.

did my test again, and the problem didn't occur, at first I thought it was just my hard to reproduce problem, but I looked in the log file and I could see that the problem was still occurring for the other footstep sounds but just not footstep_soft!

soooooo. I think that if we just re-encode all of our ogg files using the most recent vorbis tools oggenc this problem will be no more.

grab vorbis tools here

then use "oggdec.exe blahblah.ogg " to decode your ogg file to a wav file.
then use "oggenc.exe blahblah.wav" to re-encode it back to an ogg file.

I'm going to do this on all of my ogg files and hopefully the problem will be gone. I'll report back here if it happens again.

#26 I made a statement about that tool long time ago , because a converted audiofile is not always what they look like.
Messed up headers in the audio files can do very strange things in Torque and in other apps.

Have you got it working now Clint ?

#27 @Billy In fact I think that statement was to me!
more thread weaving

The problem and solution talked about in that thread sound straaaaaangely familiar :) although now its with the oggs that came with TGE and not ones I created for streaming.

I've been out of the house since my last post so haven't played with it more, but I'm pretty confident this is the problem and converting all the oggs that came with torque will make the problem go away.

I'm going to add some code that peeks at the oggs header and outputs and error to the console if it was created before a certain date. hopefully that will help warn me next time this happens. I'll let you know how it goes tomorrow.
-c

#28

Quote:
I'm going to add some code that peeks at the oggs header and outputs and error to the console if it was created before a certain date. hopefully that will help warn me next time this happens

I wasn't quite able to do this as it's not exactly the vorbis codec version that differs, but it's the version of the libvorbis used to encode the file, which if you encode it with a different tool could not even exist as a comment. So I'm just going to leave the assert and con::errors in that function that failed.

re-encoding the .oggs has made the problem go away for almost all of the files...unfortunately even after reencoding crossbow_firing.ogg and crossbow_firing_empty.ogg, they still have the problem that the footsteps used to have.

I think switching to the new audio system that uses Vorbis's code instead of the code in TGE might help.

although I wish I knew why this was _really_ happening.

two good lessons to learn from this for me:
1. if you think something is impossible, Assert! because if it ever does happen you want the user of your code to know about it, you don't want things to just go on as they were. This was a problem with the vorbis code in TGE

2. if you run into a problem (like I did before when trying to stream an ogg file), if at all possible put a warning/error message at the point in the code the problem occurred if you can detect the same situation. This will mean next time you don't spend a long time trying to find a solution when you already did months before for a similar problem

#29 I'd like to point out that most of the vorbis code in Torque was not written by Torque developers. As I recall, it was sort of merged in by a licensee, then checked into HEAD later on for one demo or another. Most of the rest of Torque's code does indeed, as Clint suggests, assert or error report when things go wrong.

Fixing the audio code is something we're actively pursuing. We'll see how it fares on our ever-crowded todo list. :)

#30 I've been using Audacity to encode ogg files. The Vorbis tools are far superior with much better compression. Thanks Billy for the pointer!

#31 Seems I get a double posting when I "go back" after checking the notify checkbox

#32 My application uses tons of sound files for spoken dialog with facial animation. I've been using the Vorbis tools to batch convert my WAV files to OGGs, but I've found about a dozen files that will lock the system when attempting to preload them. I then load them (the OGG file) into Audacity and re-export them and they work fine.

I am very concerned about the state of audio in Torque and was shocked to discover that there doesn't seem to be a way to pause sounds. I'm also running into severe synchronization issues (an animation plus audio of the same length don't finished at the same time when played simultaneously). I was researching the virtues of streaming OGG files when I foind this thread.

#33

Quote: I've been using the Vorbis tools to batch convert my WAV files to OGGs, but I've found about a dozen files that will lock the system when attempting to preload them.

This surprises me; I didn't have any problems.

Do you have a working facial animation system?

#34 Mostly. We are using FaceStation to capture the face and then apply it to the facial bones of our model. The results haven't translated all that well from the 3D package to the DSQ files. I'm not sure if it is our approach or our experience with the tools. I set a trigger in the DSQ and specify the Audio datablock in a property of my actor to call the appropriate voice. We also use a generic mouth animation for shots that aren't up close and personal.

Now back to streaming. When I play the streamed files, it loops the last buffer over and over unless I physically tell it to stop. I seem to recall seeing a reference to something like that in these Mobius Forums somewhere...

But before I go, I should mention that I have over 800 sound files that tend to be from 5-30 seconds long. I initially encoded them with the Vorbis command-line tools at a Quality setting of 3 and now am trying it at 6. Sounds that previously wouldn't load at Q3 did load at Q6, but still others fail at Q6. I'll try streaming with WAV's and OGG's at Q10 to see what happens.

#35 James, I'd probably try Marcelo's new sound resource that uses vorbis's code directly and unchanged, I suspect that it will work a bit better than what's in 1.3 head. although I haven't had a chance to try it out myself yet busy with other things lately. (see Billy's link in this thread above) please post back here with your results if you get a chance to try it.

#36 I tried that resource and got a major "lock-up". But it looks promising and I'm trying to hunt down the problem.

#37 Ok Torquiphiles, I finally tried the NewAudio Resource. I was hung up for a while when I added all the .h files but neglected to add the .cc files (I assume somewhere there's a story behind the .cc extension that I missed). However, it did solve my streaming issue!

My second issue was that I was experiencing random sutters during playback, even when the system had only a light load. This was solved in one of two ways. First, I tried replacing the OpenAL32.dll in my root with the updated one supplied in the resource. Second, I tried removing it altogether and just using the one in my XP system directory (I think they're the same file anyway).

My third issue was that there were some OGG files that locked when attempting to load. This I'm going to have to see if I run into it again as I don't feel like reprocessing all my audio as I've got to ship this thing on Friday.

I could still use a Pause function. I confess I haven't had the time to see if there was anything like it in the new resource...

#38 .cc is an old source file extension that was common on unix systems for a while.

As for sound... we're doing our best to get a rewrite done. This is an increasingly significant issue on my todo list.

#39 One more update on my audio situation. I was wrong about my second issue. The audio hiccup is still there. It seems that most files have some sort of skip about one second into streaming but is fine after that. I'm looking for some sort of off-by-one bug somewhere...