I am sure you are all experiencing this these days - overloaded ABC tunes cause your client to freeze for seconds when using the OpenAL sound driver, and also the memory footprint of lotro is changing all the time when listening to player music. This indicates that there is a lot of memory allocation/releasing going on.
This might be related to way the OpenAL driver is used by the game - and I think it is related to the reason why we always had a stuttering game when ABC tunes were overloaded.
To go into detail:
In OpenAL a number of "slots" (sound sources) are reserved which are then loaded with samples and fired off when a sound is to be played .. something like this:
std::vector<ALuint> sources(64);
alGenSources((ALuint)64, &sources[0] ); // I know this should be a proper pointer to the data
The source has also those 3D positional and volume attributes needed for the playback. Whenever a tone is to be played it is loaded into the soundbuffer of a source and fired off, the rest is handled by the OpenAL driver.
Now the tricky bit comes, the OpenAL driver can be queried if a source is still busy playing or free for something new:
ALint sourcestate;
alGetSourcei(sources[0], AL_SOURCE_STATE, &sourcestate);
if ( sourcestate == AL_PLAYING ) {} // source 0 is still busy ...
If all 64 sources are busy but you want to send something new .. you have 2 options:
1. just let the new tone fall off the wagon and don't bother because the sound system is already full
2. you decide to stop a source that is still busy and send your new sample .. this requires a sequence of commandos ...
Lotro implemented Option 2 ( which can be demonstrated by removing a stuck bagpipe drone by playing an overloaded ABC tune )
Option 1 doesn't cause any issues because instead of doing anything to the audio engine you just let it go, whereas option 2 could mess with things ...
It is my suspicion that this exact issue was always causing the lags for overloaded ABC tunes and that currently this is amplified by something else related to memory allocation.
Maybe one of the Devs could have a look into that?
Cheers,
Bruzo
This might be related to way the OpenAL driver is used by the game - and I think it is related to the reason why we always had a stuttering game when ABC tunes were overloaded.
To go into detail:
In OpenAL a number of "slots" (sound sources) are reserved which are then loaded with samples and fired off when a sound is to be played .. something like this:
std::vector<ALuint> sources(64);
alGenSources((ALuint)64, &sources[0] ); // I know this should be a proper pointer to the data
The source has also those 3D positional and volume attributes needed for the playback. Whenever a tone is to be played it is loaded into the soundbuffer of a source and fired off, the rest is handled by the OpenAL driver.
Now the tricky bit comes, the OpenAL driver can be queried if a source is still busy playing or free for something new:
ALint sourcestate;
alGetSourcei(sources[0], AL_SOURCE_STATE, &sourcestate);
if ( sourcestate == AL_PLAYING ) {} // source 0 is still busy ...
If all 64 sources are busy but you want to send something new .. you have 2 options:
1. just let the new tone fall off the wagon and don't bother because the sound system is already full
2. you decide to stop a source that is still busy and send your new sample .. this requires a sequence of commandos ...
Lotro implemented Option 2 ( which can be demonstrated by removing a stuck bagpipe drone by playing an overloaded ABC tune )
Option 1 doesn't cause any issues because instead of doing anything to the audio engine you just let it go, whereas option 2 could mess with things ...
It is my suspicion that this exact issue was always causing the lags for overloaded ABC tunes and that currently this is amplified by something else related to memory allocation.
Maybe one of the Devs could have a look into that?
Cheers,
Bruzo