Sound Upgrade

#21 Hi Stevie,

(from John Kabus)

-Download GNU utilities for Win32 from here: unxutils.sourceforge.net
-Unzip GNU Win32 onto your hard drive.
-Copy the newaudio.patch file into your Torque Folder.
-Open the command prompt navigate to the

#22 Awesome work Marcelo

#23 Stevie,

I had a similiar problem as you and this is what I did to correct it:
1) in reference to "Remove all the engine\audio files from project and add only the files included in this packet", I had to also remove these files from the build:
audioStreamSourceFactory.cc, vorbisStreamSource.cc, and wavStreamSource.cc
And be sure to include any source files that came with the .zip file.

2) change the include lib from 'vorbis_static_mt.lib' to 'vorbisfile_static.lib'

3) clean and rebuild it.

I hope that helps.

#24 With a bit of work, I've gotten this to restore sounds to TSE as well. WooHoo!

#25 Nice work and great cleanup! Addresses a poor lil neglected area of the codebase. Definitely a great candidate for test and addition to the HEAD!

#26 remove these files from the build:
audioStreamSourceFactory.cc, vorbisStreamSource.cc, and wavStreamSource.cc

#27 That's odd. Did you clean it first?

#28 Errors you're seeing is because Marcelo's patch is applied to Release 1.3, and not the lighting pack. What you need to do is make a note of what files are changed in the patch, get some ideas of what changes are made in those files, and compare that to similar calls being made in the lighting pack source files.

This will take some work on your end but the errors are provided in the compile output window, so you should be able to go directly to where the errors are and make appropriate changes.

#29 During the course of this refactoring, did you discover what causes the current memory leak in head in the ogg streaming support? Is it a bug in torque or in the ogg libraries?

#30 While it seems that memory leaks have been vanquished, I'm also intersted to hear your reply to Keith's question.

If it's possible, can you also explain any of the particulars of why XP has its own apparently unique difficulties?

Thanks

#31 @Stevie,
The patch was to the HEAD version only, but looking at the last error you posted, you should remove audioStreamSourceFactory.cc and audioStreamSourceFactory.h from your project and also remove the reference to the .h, I believe that it's in main.cc, search in files for the #include

@Keith,
No, but seems that this leak disappeared at all, the one big difference is that I'm using the vorbisfile library instead of the engine "hacked" one, this way we can easily keep up-to-date with the latest version of the ogg code.

@Dave,
Mainly there are two bugs with XP:

The first one only happens under a stress test condition when you play a lot of sounds together makes the game crashes (on openal32.dll thread) on some machines, but it doesn't happen with the latest openal dll (supplied in the resource link)

The second one is still reproductible in this version I think, try to modify the alDopplerFactor from something like 0.1 and all the sounds (even the "2d" ones) get screwed up.

Also, by using the debug version of the openaldll it reports aways two or three "unfreed" sound buffers on application exit, but I put Con::Printf() in all the buffer generation and delete functions and found that I was correctly deleting all the buffers, so I suppose that it also is a openal problem.

Unfortunately openal seems to be very bugged in the Windows at least, that's why we decided to also include DirectSound support.

#32 Marcelo said:

Quote:
Also, by using the debug version of the openaldll it reports aways two or three "unfreed" sound buffers on application exit, but I put Con::Printf() in all the buffer generation and delete functions and found that I was correctly deleting all the buffers, so I suppose that it also is a openal problem.

you might want to check for alGetError before and after your call to alDeleteBuffers it might be that there is an error deleting it, for instance if the source is playing it or if it is queued to be played. I ran into this with the 1.3 audio system.
see discussion here

#33 Not sure if I should report this here, but I've had this error on 2 different machines:

------------
Fatal: (G:\STUFF\Software\Torque_PC\engine\audio\oldaudio.cc@64)

alxCreateSource, using non-null handle
-------------

#34 @Clint,
Yes, I've done it when testing, but I'll re-check it again soon.

@Dave,
That's strange since it's a very simple stack management, this assert never appeared here, can you check if it's correctly doing garbage collecting on alxUpdate() ?

#35 We can't be sure yet that we aren't getting this 'using a non-null handle' as a symptom of something else. I was sure you could tell us where to look though. We'll post again here when we have a definite answer.

#36 Hello
Thanks for the useful resource. I am having some trouble in the build with regard to the building Precipitation.cc and PathedInterior.cc and their AUDIOHANDLE mAudioHandle. These objects are referenced/created within the oldaudio.cc file (after the upgrade) How can these be accessed to build successfully (does this need re-direction?)

Also, error on Audio::bindEAX - declared as not a member of audio , can this be explained??

Thanks, Craig

#37 Great Resource! It fixed a few bugs I was having with sound. It also compiled for me without any changes using 1.3.

-Joe

#38 I'm trying to get this to work in the TSE, and I'm down to a single compiler problem now.
I get the following error in player.cc, shapeBase.cc and pathedInterior.cc:

c:\Work\rats\engine\game\player.cpp(562) : error C2027: use of undefined type 'AudioProfile'
        ../engine\audio/audio.h(305) : see declaration of 'AudioProfile'
c:\Work\rats\engine\game\player.cpp(562) : error C2227: left of '->getId' must point to class/struct/union

The code looks like this:

for ( i = 0; i < MaxSounds; i++)
      if (stream->writeFlag(sound[i]))
         stream->writeRangedU32(packed? SimObjectId(sound[i]):
                                sound[i]->getId(),DataBlockObjectIdFirst,DataBlockObjectIdLast);

AudioProfile is just defined like this:

class AudioProfile;

That's basically it. Any clues what I did wrong?



UPDATE:

Instead of whining I could've just included...

#include "audio/audioDataBlock.h"

...to make the error go away. Duh.

#39 I have added this resource to a Lighting pack modified TGE and the sound is a much much better (I havent had a 'sound swapping' bug either which is great).

I do have one rather large problem though and wondered if anyone else has come across it (or a fix).

I have a fairly simple mission that I run specifically for testing new things. With the new audio change (the only change being the exe and dll) no one can join a hosted game. They immediately get an invalid packet error. If I swap the exe and openal.dll for the original one with no other changes then server games are fine which leads me to believe that there is a problem somewhere with the audio changes and networking. There are no problems with solo play or a hosted server (except being on your own!), just when someone tries to join a hosted server. The same thing happens if someone else runs a server - I get an immediate invalid packet error while they run around on their own.

It will be a great shame to lose the upgraded sound :(

#40 David Barr,

It looks like a missing wav (or ogg) file referenced at one datablock, does anything appears on client's console?