"Failed to pin the sample data to RAM"???

[Matt]

I keep getting this message whenever I switch to FluidSynth:

Code: Select all

Failed to pin the sample data to RAM; swapping is possible.

As far as I can tell the MIDI works fine nonetheless.

What is this???

[Graf Zahl]

This sounds like some nonsense in the audio backend. I cannot find any such text in any of the DLLs GZDoom uses.

[Rachael]

I see it a lot in the virtual Linux environments I use for GZDoom. I don't like seeing that message, but lack of RAM hasn't bothered me much so far, so I just ignore it. I figure people with more powerful systems don't get that message.

[Graf Zahl]

This warning is mostly pointless. Does it appear in GZDoom's console or only in the attached terminal?

[_mental_]

Here is the message. Please read this comment a few lines above.
User processes don't have memlock privilege by default. The message is just a reminder about that.

[Graf Zahl]

Outputting the message is plain idiotic. Even attempting to lock the memory here is idiotic. No run-of-the-mill library should even TRY doing such things.

[Edward-san]

I have always been plagued by that message every single time (not only that, but also by the long lag between the loading of the song and the message log), so this is why I'm not using fluidsynth at all (funny enough, just now I tried to switch to fluidsynth from timidity++ from the menu, but then I got a crash to desktop, I gotta make a new report when I have more info).

[Chris]

FluidSynth is intended to be usable for real-time processing, and things like swapping are a big no-no in that case because it needs to finish fast, so it tries to lock the memory used for the soundfont to keep it from getting swapped out. And even if real-time processing isn't used, locking the memory can prevent prevent random performance drops.

I don't really know what FluidSynth expects here though, given that most apps don't really care and will live just fine with the relatively-low risk of sample data getting swapped out. Printing a warning by default seems unnecessarily verbose since there's nothing a user can do to fix it (at best it's a developer message, but as previously said, it's not a big deal for most).

[Graf Zahl]

It's a "deal" because it gives the false appearance of things being broken.

But FluidSynth and real-time processing? Are you joking? That thing is notorious for being excessively CPU intensive.

[Chris]

It's a "deal" because it gives the false appearance of things being broken.

I mean it's not a big deal to most apps that the sample data isn't locked to RAM, so a message like that is unnecessary, not that the message itself isn't a big deal. I agree that the message shouldn't be just printed out like that.

But FluidSynth and real-time processing? Are you joking? That thing is notorious for being excessively CPU intensive.

Can't fault them for having aspirations. The code is structured for the mixer thread to be real-time safe, whether or not it manages to cover all its bases (the soundfont is far from everything that would need to be locked to RAM, and its use of mlock looks very naive) and get enough performance to be practical in a real-time context.