stwf
-
Posts
178 -
Joined
-
Last visited
-
Days Won
2
Posts posted by stwf
-
-
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:
-
1
-
-
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...
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...
-
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?
-
Music bugs:
- I also notice the music starting loud, then tapering off a few times to normal volume. Did something change in the implementation since the last patch I tested (patch12.diff)?
- Often the music stops abruptly in the middle of a track. This appears to occur when the game window stops responding temporarily. There are no errors in the log so it's a silent failure somewhere. Let me know if there's any debugging data I can provide as this might not be easily reproducible on newer systems:
- One way I was able to reproduce it was clearing the cache and then going to the match setup menu and while the map data was loading, the music stopped (this is a very slow process on my system). I don't know what happens technically but the music doesn't continue. In one test it occurred about 30 seconds into the main theme. Music did start with a new match.
- I've found it also occurs in-game so it's not specific to the main menu. Once the game window was minimized and the music stopped abruptly.
- I can force music to start over by toggling Menu > Settings > Enable Music so the sound system is still working in that sense. We need to find out why it stops.
[*]I just noticed the ambient sounds seem to be gone too, so it must be more than music that breaks.
[*]The music is choppy and stutters, of course if you look at the system specs it's a low-end system, but maybe we can find a way to reduce the choppiness.
- One way I was able to reproduce it was clearing the cache and then going to the match setup menu and while the map data was loading, the music stopped (this is a very slow process on my system). I don't know what happens technically but the music doesn't continue. In one test it occurred about 30 seconds into the main theme. Music did start with a new match.
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.
Music comments/suggestions:
- What should we do when the game is minimized/unfocused or paused? Currently when the game is paused regardless of being minimized, I hear ambient sounds and music. I would say when minimized and paused, either we should taper off all sound or only play music. The ambient sounds get quickly annoying in the background.
- Is music intended to loop immediately? I thought there would be periods of silence and it seems like we shouldn't loop the same track over and over, it takes away from the impact of the music. It's OK to have silence and hear the other sounds of the game
- The main menu theme in particular is one that should play only once per game IMO.
- I like AoK's use of soft ambient sounds in the background after the main theme ends, maybe we could do something like that: sounds of riders, preparations for battle, or town noises - construction, gathering, etc.
- The main menu theme in particular is one that should play only once per game IMO.
Unit voice response:
- Seems to work much better now, I even hear off screen units responding and camera seems to have no impact
- One thing that annoys me: when double clicking units, I hear a voice response for each click. It creates a repetitive sound for double and triple clicks. I think the better behavior would be to either not interrupt the sound from the first click or wait to play a response until the UI determines if it's a single or double click (but that seems trickier and prone to error).
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 also notice the music starting loud, then tapering off a few times to normal volume. Did something change in the implementation since the last patch I tested (patch12.diff)?
-
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!
-
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....
-
1
-
-
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
-
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...
-
1
-
-
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.
Brilliant work!
Does the Gain value work in the new sound manager? In most cases it should already be set to balance the sounds. Otherwise I can go through and make changes after it's committed.
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.
In this case make sure you use vorbisgain (supposing 0 A.D. is compatible with it) to do it, to avoid losing audio quality.
Other audio suggestion here.
Might be possible to get battle detection in and update the sound system. Just posting this here for reference.
[edit] Just realized that's not public, so that link isn't much good for you.
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...
New Sound Manager svn patch
in Game Development & Technical Discussion
Posted
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