OPL music buffer

[Csonicgo]

Is it possible to increase (or add the ability to change the size of) the buffer for OPL music output? on some of my machines the buffer can empty too quickly when a bunch of notes hit at once, causing a spike in CPU usage. having a few seconds "ahead" would help a lot - even if it causes music changes to lag.

[Graf Zahl]

There is no such buffer. The entire streaming system will request a certain chunk of data to stream next from the currently played music and that is defined by the sound system. If you are having issues the problems are there.

You say 'some of your machines'. What's the specs of those?

[Chris]

There is no such buffer.

When an audio stream is created it tells the sound renderer how big of a buffer to use, which in turn is how much audio is requested whenever more audio is needed. Internally it uses a set number of individual buffers, each with the given buffer size. Every music backend seems to handle the specified buffer size on its own, without any standard control mechanism (different softsynth midi devices specify a hardcoded samplerate divisor for either 2 or 14 updates per second, dumb and gme specify a hardcoded 32KB buffer size, music_libsndfile uses snd_streambuffersize*1024, the timidity pipe uses timidity_pipe as the update size in milliseconds..). It's all pretty convoluted with various hard-coded parameters set by various callers, and different music backends using different cvars (if any).

I think it would be better if the music backends don't worry about this, and just have one or two cvars (snd_streambuffersize and snd_streambuffercount) that the audio backend uses irrespective of the format.

[Graf Zahl]

Hm. I never expected this to be such a mess. The music code was never really on my radar except for the occasional fix.

Interestingly most players use 32kb, the change for the sndfile player was relatively recent, no idea why it was only applied to this one player and not all. And the OPL buffer really looks a bit small compared to the rest.

You are correct, of course. It should really be the backend which decides what buffer size to use, it knows best, after all, what size causes the least problems. I actually would have expected that this was how it worked.

[_mental_]

snd_streambuffersize CVAR controlled the size of FMOD stream buffer and as far as I know it was applied to sample-based formats only.
After removal of FMOD an issue with streaming buffer exhaustion reappeared (high quality FLACs were affected by it) so I re-added the CVAR there.
Honestly I thought that it's not applicable other music backends.

[Csonicgo]

You say 'some of your machines'. What's the specs of those?

These are the ARM-based machines, and NEON intrinsics aren't implemented yet.

Some lower-end machines like my Intel Atom netbook would also benefit, although I'm quite aware of the limits of those.

[Csonicgo]

Hm. I never expected this to be such a mess. The music code was never really on my radar except for the occasional fix.

Interestingly most players use 32kb, the change for the sndfile player was relatively recent, no idea why it was only applied to this one player and not all. And the OPL buffer really looks a bit small compared to the rest.

You are correct, of course. It should really be the backend which decides what buffer size to use, it knows best, after all, what size causes the least problems. I actually would have expected that this was how it worked.

Can you point out where that OPL buffer code is located? I would like to take a look at it.

[Chris]

Can you point out where that OPL buffer code is located? I would like to take a look at it.

In src/sound/mididevices/music_opl_mididevice.cpp, there is:

Code: Select all

int OPLMIDIDevice::Open(MidiCallback callback, void *userdata)
{
        if (io == NULL || 0 == (NumChips = io->Init(opl_numchips, FullPan, true)))
        {
                return 1;
        }
        int ret = OpenStream(14, (FullPan || io->IsOPL3) ? 0 : SoundStream::Mono, callback, userdata);
        ...
}

That 14 is the frequency of buffer updates, or put another way, the divisor for the buffer size (i.e. the buffer size in samples is SampleRate/14). Reducing that value will increase the buffer size. Setting it to something around 4 or 5 would probably be better.

[Csonicgo]

You saved the day, there. Thanks!