Fix for music restarting after cell change. Bug 145

[werdanith]

I found the cause for this bug. At least the music restarting part.

The problem is with the OpenAL implementation of the Music Streamer.

Music in OpenMW is streamed with the help of a buffer in order to avoid writing the entire audio file to memory. The problem is that the buffer doesn't get filled when the game is loading and lasts for less than a second. So if the game freezes for more than that, the buffer runs out and the streaming ends. After the game loads, it figures out that there is no music and starts up again.

Anyway, what I was going to ask is how long do we expect the game to load for, in the worst case scenario?
I estimate that a buffer of 5 buys us 1 second (and up until now it was 4). In my netbook, going from Beshara to Balmora takes a full 10 seconds, on even crappier hardware with even more cluttered cells it could arguably take more. So how much is a reasonable value for the buffer? We could set it to 2000 but that would defeat the purpose of using streaming in the first place, unless somebody uses 20 hour tracks in their Music folder.

Also I might need some help with committing the changes that need to happen in Mangle. The whole github submodule thing is a bit confusing.

[Zini]

Anyway, what I was going to ask is how long do we expect the game to load for, in the worst case scenario?

That is entirely impossible to predict. Hardware factors in, obviously. But the data in the ESX files might affect the load time too. I suspect that we will have to look into a more multithreading-ish solution at some point.

Also I might need some help with committing the changes that need to happen in Mangle. The whole github submodule thing is a bit confusing.

Yeah, that is tricky.

1. Fork the submodule on github
2. cd into the local location of the submodule (in your local OpenMW repository)
3. add your fork as a remote

4. Make sure you have a branch checked out
5. make the desired changes and commit
6. push to github
7. cd up to the OpenMW directory
8. commit the submodule changes
9. push to github

[werdanith]

Ok, I'm setting it to 150 for 30 seconds, it doesn't sound like a memory hog, and if the game is stuck for more than 30 seconds you have more serious problems than the music that stops playing.

Okay, now onto the submodule stuff.

[Zini]

Please make sure that you branch of from next (both on OpenMW and on OpenEngine)!

If you are not registered on the bug tracker yet, you should do so now. Otherwise the task can't be officially assigned to you.

[werdanith]

Okay, I think I pulled it off.
I am registered on the bug tracker, although about the bug, the bug refers to sound effects playing over and over and I can't say I've noticed that behavior, or that my fix fixes it.

Edit: also I've noticed that there are some mangle updates not present in your master branch, so I can't help wondering, did I clone the wrong branch?

[Zini]

Doesn't look like it. We didn't touch mangle for ages. I will review the situation tomorrow.

[Chris]

Ok, I'm setting it to 150 for 30 seconds, it doesn't sound like a memory hog, and if the game is stuck for more than 30 seconds you have more serious problems than the music that stops playing.

30 seconds at 44.1khz 16-bit stereo is 5,292,000 bytes (a bit over 5MB) just for the buffered data... assuming it's stored internally using 16-bit samples and not float or something, then it's more. IMO that's way too high, as normal operation would only need 1 second at most.

I think a better fix is to make sure music and sounds keep getting processed while cells and stuff are loading. Stuff needs to keep getting processed anyway if you want to have progress bars or whatever. Music processing itself can even go into a separate thread (that's essentially what DirectShow does, which Morrowind uses for music playback). A thread whose sole purpose is to periodically check if more audio is needed for a stream, and decode and feed it as needed.

[werdanith]

30 seconds at 44.1khz 16-bit stereo is 5,292,000 bytes (a bit over 5MB) just for the buffered data... assuming it's stored internally using 16-bit samples and not float or something, then it's more. IMO that's way too high, as normal operation would only need 1 second at most.

The size of the buffer is 32*1024. I can't figure out whether it's bits or bytes, but by your math bytes sounds right. For 150 of these we get a size of 4.68 MB. I did assume it would be less. Currently though from my understanding there are far worse memory leaks in the engine.

I think a better fix is to make sure music and sounds keep getting processed while cells and stuff are loading. Stuff needs to keep getting processed anyway if you want to have progress bars or whatever. Music processing itself can even go into a separate thread (that's essentially what DirectShow does, which Morrowind uses for music playback). A thread whose sole purpose is to periodically check if more audio is needed for a stream, and decode and feed it as needed.

Agreed, but I don't know how to implement that, if anyone can, then they are more than welcome to do so.

[Zini]

I did assume it would be less. Currently though from my understanding there are far worse memory leaks in the engine.

There shouldn't be any at all. If there are, then it is an undiscovered bug.

[werdanith]

There shouldn't be any at all. If there are, then it is an undiscovered bug.

I have managed to crash the game after visiting a large number of cells with an error message that sounded like a memory leak. I have no data to back it up though. And there have been reports such as this:

I've been unable to reproduce the cell-changing problems, the closest thing I've found is that the cells aren't loaded/unloaded properly as memory usage increases every time the cell is reloaded