stwf

OK, thanks I don't get any of those errors on the mac... and its hard to see warnings, but this new version was built in linux too and seems to work fine. Thanks for the testing... archiveStream_2.diff

yup. late night editing issues!

ok, here is the completed and corrected svn patchI ca't seem to get this file attached. It is attached here in the trac issue: http://trac.wildfire...com/ticket/1604 archiveStream.diff

argh, I accidentally checked in some binaries to my branch...

OK, the fixed version is up in my git fork at: https://github.com/stwf/0ad/tree/ogg-streams I'll prepare and upload the svn patch tomorrow. But in case anyone wants to take a look in the meantime. This should fix all of the known issues and contain enough logging to help track down the trickier ones.

Thanks, I will incorporate all of those things. Currently I am adding error handling for initialization (and better disabling if init fails) also I'll check and log errors during playback to try and nail down the intermittent problems. I was going to try and support the builds without audio as well as starting from the command line without audio as well. I will increase the buffer size for the alpha but I think using a thread for feeding openal is the right solution for that. Thanks for the testing and advice

OK, fix in for the archive problem! It actually fit in kind of nicely! RIght now its in brnach on git at: https://github.com/stwf/0ad/tree/ogg-streams Sorry for those who were watching my fork, I deleted it and started over. #afraidofgit I did have one time where the main menu music stopped, but I couldn't reproduce it, so we may not be out of the woods yet...

You should look into sparkle... http://sparkle.andymatuschak.org/ Its a framework that makes auto updates very easy (but it is Mac only). A brief perusal of their website shows that they do have a way to support code signing...

THings are starting to free up for me, especially next week, so I plan on being able to put some time in on this... Seems the main issue is the archive thing (I will lurk around IRC to discuss how to handle that), also to handle being disabled from the command line and/or due to errors in the startup. Then moving the sound processing into another thread as a possibly next version upgrade, does that sound about right?

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

Thanks for the input! I'll tackle these one by one... 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. 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... 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...

ok! Here is a new patch. It fixes the compiler warnings as well as the segfault (probably) although I'm not entirely sure why that happened. Maybe a missing resource. I added a log message when that happens to help track it down. Also the loud music start is gone, oops. The previously mentioned issue with the build files being mac only, is that something I need? I don't remember adding it, is it safe to take it out? RealPatch2.diff

I see the music volume problem, I'll get that fixed and in a patch soon. Also with the compilation warnings, its tough on the mac because of all of the warnings Boost generates... Thanks for the testing... 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. 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? Right now I'm not running any extra threads for this. I think it could be done in an outside thread if necessary OpenAL is pretty much thread safe although of course thats really up to each implementation. All of the other suggestions won't be a problem to implement, we just need to determine exactly what should happen. Yes, its supposed to just repeat and repeat (in my mind). So that can be made to not happen of course... 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 guess the issue I worry most about is underpowered machines and if the new sound code was causing a lag that wasn't there previously. I used a more object oriented approach thn the old code and that does come with some slight performance trade offs. Otherwise I am pretty sure it isn't leaking memory, which could always be a concern, and the code for running under low memory hasn't been very well tested. Overall I'm glad to see the code working!

ok, here is the new patch. I ran it against the trunk and it then built. So everything should be in here... I'll be away until Friday, so I won't be able to fix any issues until then... Good Luck! RealPatch1.diff

I'm really sorry for the delays in finishing this up. THe life of someone married to a teacher changes drastically in the summer! Less tired wife == less coding time! I do have an up to date version, that merges cleanly with the current trunk. I'll upload those patches tonight. I think it would be good to get that code into the next full out release. Then we could get a start on addressing the real world bugs. I had one chance to try and get the rolloff working right but couldn't. I just need to sit down with the maths and figure it out right once. Hopefully soon I can do that.

Hello All, Just to let you know I'm back on the case! Sorry about the errors in the patch, I'm coding in a git environ, then using some cmd line stuff to move it into a svn derived branch. This process copies over new files, but for some reason doesn't add them to the svn tree. So until I do that they don't get included in the patch. I will put a press on to get this done this month. It should not be a problem....

Hi Guys, Sorry for the absence. I'll be away and off internet for next week. As such I had a TON of work to get done before I left. Here is a patch for my latest work (also checked into my branch on github). The state is: The issues with acknowledgements have been fixed, and some other bugs about the screen area that may have caused historic_brunos issues with battle. I have confirmed that the gain values specified in the xml fiels are being honored. So getting the volumes balanced should just be an issue of setting those values right. There are 2 remaining known issues. Getting the volume rollofff right, the simple exponential rolloff won't do. I need to use of of the more complicated modes to keep the sounds loud when you are close, but silent when you are zoomed out. Private sound issue. Some sounds of your opponents (I guess the ones that are set to Omnipresent) can be heard by all players. I'll be able to get right on these when I return... steve good_sounds.patch

Here's a crazy idea... How about make the battle music be controlled by the player, and confer some sort of advantage in battle? Make it sort of an overall health, some heroes could bring more than others, and it would run down over time. The player would choose when to go into battle mode, and when to turn it off and save some juice. While the music was on units could perform better, as it wore down the effect could lessen, thus stimulating a battle fatigue. OK, too much, right? I'll go back to coding now...

OK, Thanks for the feedback. I'll investigate all of those. Adding new voices should be pretty easy, we can either create new Javascript objects like I did for Ambient sound and Music, or create some flags and place them in the xml files. Speaking of which the gain for each sound is set in the xml. Some sounds have bounds for a high and low range that gets randomly played in that range. I'll do some double-checking to make sure all of those values are being applied correctly, after that it will just be a matter of setting the values in the xml file right. The easy one problem will be the acknowledgements. They should have the distanceless flag set. This will allow them to be heard wherever they are on the screen. I'll try and get that checked in, at least where I can find them. The battle thing is odd, I'll look at that. Aso I can raise the falloff value on zoom out. I didn't realize you really wanted to hear nothing but music and sounds at full zoom! Finally I'm not quite clear on the building sounds... Should I be filtering that out, or is it up to the engine to only send the right sounds to the sound manager?

OK, the long awaited final version of the first pass of the sound manager is here. Should build and run cleanly on Mac, linux and Windows. I'll keep on the lookout for bug reports... fingers crossed... patch12.diff

Thanks to historic_bruno and others I have fixed all of the problems and will be pushing the final version up tonight. It's functionally the same as the current version but without the warnings and assertions on Windows. Yes, the gain being set through the xml files is being honored although I'll take another look and double check. But if not thats a bug I can fix. So that should be enough to rebalance the sound. Since we're nearing the end of Phase 1 of this system, to get something stable and working. I'd love to move on and start adding new features and support. Most of these things will require developer support, so its more up to the community which ones they want and will implement (or be willing to lose control of)...

Here is the assertion I keep getting, on the Windows build only

The code is up in my github branch, but I'm having a windows build problem. So, one more day delay...

hmm, wow that was a mistake. I did upload the wrong one. I apologize for the time wasted... The good news is that the directionality is done and will get uploaded tonight. I think the overall workings of it should get tweaked over a couple of iterations, the first pass is handled like this. Objects on the screen or in the a 10% buffer area around the screen are laid out as they appear horizontally on the screen with the sides of the screen at 60 degrees off center, all at a constant distance that is equal to the height of the camera. The volume rolloff is handled is set as exponential, so the higher the camera is the quieter all of the placed sounds are. The only other modification is that items in the 10% buffer around the screen get triple volume rolloff as items on the screen, so they will always sound quieter than similar sounds on screen. Anything outside of the 10% buffer just isn't played, although I do support the eOmnipresent flag that plays the sound at the same location as the listener. Also I added a flag eDistanceless that will play a sound at a location whether or not it is on the screen. Sounds with this flag set get pinned to 70 degrees maximum right or left of center, since the object would be to get the user to scroll the map to the right or left, not to look behind themselves! As always all comments or questions welcome...