New Sound Manager svn patch

[MishFTW]

Okay so this time, with the right folder, it sort of worked.

I opened the pyrogenesis and this is what I got in terminal

Last login: Wed Aug  8 12:16:28 on ttys000
iMac:~ Geek$ /Users/Geek/0ad/binaries/system/pyrogenesis ; exit;
dyld: Library not loaded: /usr/local/lib/libjpeg.8.dylib
  Referenced from: /Users/Geek/0ad/binaries/system/libnvimage.dylib
  Reason: image not found
Trace/BPT trap
logout
[Process completed]

[historic_bruno]

There's a bug with sound in Atlas simulation test, resetting the simulation doesn't stop the sounds, so music and ambient effects continue playing endlessly, even if a new map is loaded.

As for the stopping, that happens when there is too much time between calls to the idle function. Once this happens the music would need to be restarted. I can check each time through, and if the music isn't playing when it should be, restart it. But it would be best if it didn't happen.

Yeah that sounds less than ideal. It goes back to the need for a threaded music manager. Music should be independent of the engine/renderer thread (although both simulation and UI should be able to trigger music changes, the music manager should decide exactly how and when the transition occurs and what to do at the low-level). Not all sounds need this, just ones that play for long periods across multiple UI pages, e.g. music.

As far as the repeating music goes, it will get very tiring as you can imagine over a 1-2 hour or longer game. A music manager system could have a playlist with built-in periods of silence, not to mention being able to randomly select and mix in different tracks, and I think it would be really cool if the user could even add their own music collection as an option.

I'm satisfied with how it works now as an initial version, but these problems will need to be tackled next which is why I bring them up now, it can start the discussion

I added the buffer size as an item inside the default.cfg file. sound.bufferSize = 65536. I think making that larger will allow for longer times to go by without the idle proc being called. So could you change that on your system and let me know if it helps?

What is the impact of a larger buffer size? Do all sounds use the same buffer size, is it in bytes? Is it per-sound or one for the whole sound system? A larger buffer might help as a workaround, I still think a multithreaded music manager is the best long term solution.

My informal test results: increasing the buffer size to 96k eliminated the stoppage during initial loading of the game setup page (very slow because it parses and caches a bunch of XML data) and the music continued even during giant random map generation.

I think what you mean about the double clicking is a javascript issue, right? I could monitor if a given source was playing a certain sound, etc. But the best solution would be to just do what the javascript engine tells me...

I'm not exactly sure what should happen when multi-entity selection occurs. From an aesthetic point of view, it shouldn't play multiple selection sounds simultaneously

I think we discussed in the past one possible solution for handling multiple sounds playing simultaneously by adjusting the volume of the first instance of the sound, rather than playing them all. It seems like there should also be a cooldown period which varies per sound, during which the same sound can't play again (in battles all I hear is "Ugggh!" "aggggh!" "hooogh!" "Ugggh!" "aggggh!" "agggh!" ...) It could also switch to a special "group" or "chorus" sound when specified for the sound type, maybe when a given threshold of requests to play the sound is hit.

It's the same problem but even more important with battle sounds, we shouldn't hear dozens of arrows, sword blows or deaths at once, instead the sound engine can switch to "group battle" sounds. The sound engine seems the likeliest candidate to handle that stuff, otherwise lots of sound implementation concerns creep into the simulation and UI, not to mention it's such a fundamental part of the sound system.

Again this isn't critical to get perfect in the first version and in fact the old sound system was no better, but as soon as it's committed it becomes a TODO. No doubt the art and sound teams will have lots of suggestions once they can test it.

The main menu music seems to end a bit abruptly when switching from the "starting a game" screen to the actual game (it doesn't do it when resigning, on the other hand).

I agree, there should be a smooth faded transition.

[wraitii]

think we discussed in the past one possible solution for handling multiple sounds playing simultaneously by adjusting the volume of the first instance of the sound, rather than playing them all. It seems like there should also be a cooldown period which varies per sound, during which the same sound can't play again (in battles all I hear is "Ugggh!" "aggggh!" "hooogh!" "Ugggh!" "aggggh!" "agggh!" ...) It could also switch to a special "group" or "chorus" sound when specified for the sound type, maybe when a given threshold of requests to play the sound is hit.

It's the same problem but even more important with battle sounds, we shouldn't hear dozens of arrows, sword blows or deaths at once, instead the sound engine can switch to "group battle" sounds. The sound engine seems the likeliest candidate to handle that stuff, otherwise lots of sound implementation concerns creep into the simulation and UI, not to mention it's such a fundamental part of the sound system.

I'm with you here. I think battle detection should not only be implemented for battle music, but for battle ambient sounds.

geek: have you installed the dependencies with macports? It looks like the "libjpeg" library has not been installed on your computer.

[stwf]

Thanks for the input! I'll tackle these one by one...

There's a bug with sound in Atlas simulation test, resetting the simulation doesn't stop the sounds, so music and ambient effects continue playing endlessly, even if a new map is loaded.

Last time I tried I couldn't build atlas. I update_workspaces with the --disable-atlas option. I'll try to do it again and recreate this.

Yeah that sounds less than ideal. It goes back to the need for a threaded music manager. Music should be independent of the engine/renderer thread (although both simulation and UI should be able to trigger music changes, the music manager should decide exactly how and when the transition occurs and what to do at the low-level). Not all sounds need this, just ones that play for long periods across multiple UI pages, e.g. music.

Any recommendations on threading here? Can I use the boost threads? I'll try and keep it as simple as possible since threading can be such a platform dependent thing. But it's a little more complicated, I'll explain below...

What is the impact of a larger buffer size? Do all sounds use the same buffer size, is it in bytes? Is it per-sound or one for the whole sound system? A larger buffer might help as a workaround, I still think a multithreaded music manager is the best long term solution.

My informal test results: increasing the buffer size to 96k eliminated the stoppage during initial loading of the game setup page (very slow because it parses and caches a bunch of XML data) and the music continued even during giant random map generation.

The buffer size is per sound, but is really only a maximum, small sounds only use the RAM they need. The most efficient use of OpenAL (especially when repeating) is to load sounds into one buffer and play it, or set it to repeat. So you have to decide at which point you decide to break things up. This is the buffer size.

The second way to play is to load things into multiple buffers and then add them to queues and deque them when done. The sound manager handles this as well as requeueing for those that repeat. But it isn't as efficient as letting OpenAL handle this. Again you just need to decide up to what size you are going to try and hold the whole sound in memory.

The third situation (used for music and ambients I think) is when the sound can't be held in memory all at once. You decide how many buffers you can hold in RAM (currently 5) at that point I have to queue the 5 buffers and as they are unqueued read more file in and queue them, so on and so on.

So technically OpenAL is always playing the sounds in a separate thread, as long as it has data. So the larger or more buffers queued the longer OpenAL can play without intervention. What will also need to be moved into the threads is this maintaining of repeating queues and/or file streaming. That is the part of this that currently needs some idle time to complete. Again not a huge deal, but a little work needs to be done. All in all we will be much better off for it, probably will be able to shorten the buffers and save RAM.

I hope that was clear enough. All of the other points I think are details that will be easy to implement once we get clear how it should work.

I hope to get something in the threading soon. I may chat you up on IRC for some advice...

[fabio]

As a later TODO it would be nice to include support for the opus codec (wikipedia), it has a better quality than vorbis (especially with small files), and can eventually also be used for in-game chat.

Edited August 10, 2012 by fabio

[historic_bruno]

Last time I tried I couldn't build atlas. I update_workspaces with the --disable-atlas option. I'll try to do it again and recreate this.

The usual problem on OS X is having the wrong version of wxWidgets or building it with the wrong options. So just make sure to use wxWidgets 2.9.x and that it was built with GL canvas enabled (--with-opengl was passed to ./configure). If you use something like MacPorts or Homebrew, the same advice applies.

Any recommendations on threading here? Can I use the boost threads? I'll try and keep it as simple as possible since threading can be such a platform dependent thing. But it's a little more complicated, I'll explain below...

Luckily we already have a cross platform solution for threading, the game uses standard POSIX threads API and there's a Windows implementation included It's easy to use, for examples see CMapGeneratorWorker, CUserReporterWorker, CTextureConverter, CNetServerWorker.

Thanks for the information, that clarifies things.

[historic_bruno]

What's the status of this? If there are no changes anticipated in the patch this week, let's move forward with committing it.

[k776]

Last time I tested it, it worked quite nicely without any issues. I suggest we approach this like we did for the graphical improvements. If the source is clean and matches the coding conventions, and any old code is gone (not left behind), I suggest commiting the bulk of the work, and then people can test, report feedback, and make tweaks.

[feneur]

Last time I tested it, it worked quite nicely without any issues. I suggest we approach this like we did for the graphical improvements. If the source is clean and matches the coding conventions, and any old code is gone (not left behind), I suggest commiting the bulk of the work, and then people can test, report feedback, and make tweaks.

Sounds like it's time to get it in SVN so we can have it tested before the release

[dvangennip]

I do have a an error that, at least in my case, is reproducible. Start any game, and simply resign. It gives the error pasted below on the command line.

vfs.cpp(203): Function call failed: return value was -110101 (VFS file not found)
Function call failed: return value was -110101 (VFS file not found)
Location: vfs.cpp:203 (GetRealPath)

A more complete crash window feedback was given by OS X. The full details can be seen in the attached text file. Hopefully this helps in debugging.

Edit: I tried again with gdb, and it gave this stacktrace (better info compared to crash log of OS X):

#0  0x00007fff895fd0b6 in __kill ()
#1  0x00000001003e90ff in VFS::GetRealPath (this=<value temporarily unavailable, due to optimizations>, pathname=@0x1436b49c0, realPathname=@0x7fff5fbfd3f0) at ../../../source/lib/file/vfs/vfs.cpp:203
#2  0x00000001001bf608 in CSoundData::SoundDataFromOgg (itemPath=0x1436b49c0) at ../../../source/soundmanager/data/CSoundData.cpp:99
#3  0x00000001001bfb54 in CSoundData::SoundDataFromFile (itemPath=0x1436b49c0) at ../../../source/soundmanager/data/CSoundData.cpp:78
#4  0x00000001001bdd73 in CSoundManager::LoadItem (this=0x10165aa30, itemPath=<value temporarily unavailable, due to optimizations>) at ../../../source/soundmanager/CSoundManager.cpp:143
#5  0x00000001001c608c in JMusicSound::Play (this=<value temporarily unavailable, due to optimizations>) at ../../../source/soundmanager/js/JMusicSound.cpp:40
#6  0x00000001001c726f in CNativeFunction<JMusicSound, false, bool, &(JMusicSound::Play(JSContext*, unsigned int, unsigned long long*))>::JSFunction (cx=0x102241ba0, argc=0, vp=0x12c22d318) at ScriptableObject.h:188

resign_CSoundData_VFS_error.txt

Edited August 14, 2012 by dvangennip

[historic_bruno]

I do have a an error that, at least in my case, is reproducible. Start any game, and simply resign. It gives the error pasted below on the command line.

Thanks for reporting I encountered that error as well, it's just because the "defeat cue" music file was removed from SVN, so I've fixed that and left a comment. I don't really understand the purpose of the defeat cue.

[historic_bruno]

OK folks, the new sound system has been committed, now time for testing. Go go go

[zoot]

Works fine for me. Nothing to report

[Loki1950]

Works fine here too that's on Win 7

Enjoy the Choice

[Mythos_Ruler]

Breaks the game here. No music. Select an object and get a crash.

http://trac.wildfiregames.com/ticket/1592

May or may not have anything to do with the new sound system.

[Enrique]

Hi,

After updating SVN no sound at all is played. No errors, just there is no sound. Windows 7 user.

system_info.txt

[Pureon]

Are you both using the manual build?

[Mythos_Ruler]

Are you both using the manual build?

I'm using whatever build is in SVN at the moment.

[Shield Bearer]

Works fine for me

[historic_bruno]

Hmm sounds like a difference in hardware or drivers, since it's working for some people in Windows but not others. The question is why it worked before.

Unfortunately for Vista or later, our system info detection fails to detect sound driver versions So I'd suggest opening up Control Panel and go to Device Manager > Sound, video and game controllers and view properties of the sound devices listed in system_info.txt, then list the Driver info here.

AMD High Definition Audio Device
Advanced Micro Devices
2/23/2012
7.12.0.7706

Realtek High Definition Audio
Realtek Semiconductor Corp.
6/14/2011
6.0.1.6392

[Mythos_Ruler]

VIA Technologies, Inc.
8/4/2010
6.0.1.8700

"Update Driver..." claims it is up to date.

[historic_bruno]

OK, I've committed a new build to SVN with some added debug output. Previously the OpenAL init may have failed silently.

For those who don't know, you can use DebugView on Windows to view the debug output, just run that utility followed by the game, DebugView will log the output. The relevant line to look for is "Sound: AlcInit ..." which should tell us if it failed and possibly why.

[Mythos_Ruler]

Here's my crash logs with your new exe. (attached)

And here's my debug view. I see some interesting stuff @ 0.017. Hopefully that will give a clue.

00000001 0.00000000 [5716] HRT: activating HPET failed: Unknown error (-100022, 0xFFFFFFFFFFFE794A) 
00000002 0.00008222 [5716] HRT: using name=TSC freq=3013000000.000000 
00000003 0.00010975 [5716] HRT: counter=TSC freq=3.013e+009 res=3.31895e-010 bits=64 
00000004 0.00238656 [5716] Cache: 200 (total: 4096) MiB 
00000005 0.00342219 [5716] TIMER| InitVfs: 1.65926 ms 
00000006 0.01748266 [5716] Sound: AlcInit failed, m_Device=00000000 m_Context=002E0041 dev_name=DirectSound Software err=40964 
00000007 0.01900790 [5716] TIMER| InitScripting: 1.40089 ms 
00000008 0.02905294 [5716] TIMER| CONFIG_Init: 9.93925 ms 
00000009 0.86245048 [5716] TIMER| RunHardwareDetection: 152.487 ms 
00000010 0.90543211 [5716] TIMER| write_sys_info: 42.774 ms 
00000011 0.91040635 [5716] TIMER| InitRenderer: 2.91257 ms 
00000012 0.91851026 [5716] TIMER| ps_console: 7.85572 ms 
00000013 0.92047417 [5716] TIMER| ps_lang_hotkeys: 1.4695 ms 
00000014 0.92313898 [5716] TIMER| common/setup.xml: 1.89479 ms 
00000015 0.92347807 [5716] TIMER| common/styles.xml: 251.545 us 
00000016 0.92822576 [5716] TIMER| common/sprite1.xml: 4.40176 ms 
00000017 0.93247020 [5716] TIMER| common/init.xml: 4.3218 ms 
00000018 0.95497704 [5716] TIMER| common/common_sprites.xml: 5.64724 ms 
00000019 0.96148133 [5716] TIMER| common/common_styles.xml: 932.473 us 
00000020 0.96769816 [5716] TIMER| pregame/sprites.xml: 1.56915 ms 
00000021 0.97372603 [5716] TIMER| pregame/styles.xml: 305.046 us 
00000022 0.98445505 [5716] TIMER| pregame/mainmenu.xml: 16.5553 ms 
00000023 0.98551005 [5716] TIMER| common/global.xml: 932.863 us 
00000024 3.69197679 [5716] TIMER| common/setup.xml: 1.25239 ms 
00000025 3.69211984 [5716] TIMER| common/styles.xml: 77.1447 us 
00000026 3.69634271 [5716] TIMER| common/sprite1.xml: 4.1719 ms 
00000027 3.70164704 [5716] TIMER| common/common_sprites.xml: 5.23867 ms 
00000028 3.70242739 [5716] TIMER| common/common_styles.xml: 725.674 us 
00000029 3.70328999 [5716] TIMER| gamesetup/setup.xml: 765.488 us 
00000030 3.70359135 [5716] TIMER| gamesetup/sprites.xml: 219.982 us 
00000031 3.70388818 [5716] TIMER| gamesetup/styles.xml: 227.649 us 
00000032 3.73344040 [5716] TIMER| gamesetup/gamesetup.xml: 29.4381 ms 
00000033 5.93690300 [5716] TIMER| common/setup.xml: 1.29832 ms 
00000034 5.93708086 [5716] TIMER| common/styles.xml: 83.6731 us 
00000035 5.94127846 [5716] TIMER| common/sprite1.xml: 4.1436 ms 
00000036 5.94493437 [5716] TIMER| common/init.xml: 3.41919 ms 
00000037 5.95016098 [5716] TIMER| common/common_sprites.xml: 5.13439 ms 
00000038 5.95093536 [5716] TIMER| common/common_styles.xml: 721.271 us 
00000039 5.95158291 [5716] TIMER| loading/styles.xml: 555.666 us 
00000040 5.95258665 [5716] TIMER| loading/sprites.xml: 912.476 us 
00000041 5.95574808 [5716] TIMER| loading/loading.xml: 3.02516 ms 
00000042 5.95643091 [5716] TIMER| common/global.xml: 602.102 us 
00000043 7.98464346 [5716] TIMER| common/setup.xml: 1.26647 ms 
00000044 7.98483181 [5716] TIMER| common/styles.xml: 84.8228 us 
00000045 7.98894644 [5716] TIMER| common/sprite1.xml: 4.06409 ms 
00000046 7.98937941 [5716] TIMER| common/icon_sprites.xml: 342.229 us 
00000047 7.99454451 [5716] TIMER| common/common_sprites.xml: 5.0938 ms 
00000048 7.99530697 [5716] TIMER| common/common_styles.xml: 714.556 us 
00000049 8.00291348 [5716] TIMER| session/sprites.xml: 7.48635 ms 
00000050 8.00382805 [5716] TIMER| session/styles.xml: 806.438 us 
00000051 8.13015652 [5716] TIMER| session/session.xml: 126.222 ms 
00000052 8.13261604 [5716] TIMER| common/global.xml: 2.32609 ms 
00000053 8.20497799 [5716] sound item could not be loaded to loop: audio/ambient/dayscape/day_temperate_gen_03.ogg 
00000054 8.24750137 [5716] GAME STARTED, ALL INIT COMPLETE 
00000055 11.29394436 [5716] ERROR: error loading sound: pathname=audio/interface/select/building/sel_civ_center.ogg, error=No error reported here 
00000056 11.46889496 [5716] unknown(0): Much to our regret we must report the program has encountered an error.  
00000057 11.46889496 [5716]   
00000058 11.46889496 [5716] Please let us know at http://trac.wildfiregames.com/ and attach the crashlog.txt and crashlog.dmp files.  
00000059 11.46889496 [5716]   
00000060 11.46889496 [5716] Details: unhandled exception (Access violation reading 0x00000000)  
00000061 11.46889496 [5716]  

crash.zip

[stwf]

hmmm, my Windows setup does seem to be working fine.. But I'll do some research and see if I can figure this out....

[historic_bruno]

hmmm, my Windows setup does seem to be working fine.. But I'll do some research and see if I can figure this out....

We've been discussing this a bit in IRC today. I did some investigation into the old snd_mgr and the new, the big difference I see in OpenAL initialization is that previously it occurred on demand, when a sound was first opened, now it happens early in the game's init process. I also dug into the SVN history and couldn't find any reason for the on-demand init, other than maybe a slight decrease in the game's startup time. But maybe if that code hadn't changed in at least 8 years, it was covering up some other problems we are now encountering?

It works for me too, both on my old 32-bit WinXP and my new 64-bit Win7 PC. I also tested on OS X and it works fine.