Output console flooded with "MidiInAlsa: message queue limit reached!!"

[basshelal]

I'm developing a Java library that binds RtMidi to Java using JNA, everything so far works very well except for one issue.

Steps to reproduce the problem.

Whenever I create an RtMidiInPtr using either rtmidi_in_create() or rtmidi_in_create_default() after I send enough messages to fill the queue (RtMidi's default is 100, but set anything over 0, 0 causes a segfault later in MidiInApi::MidiQueue::push(MidiInApi::MidiMessage const&)), any further messages will print to the console MidiInAlsa: message queue limit reached!!.

Expected behavior and actual behavior.

I'm unsure if this is supposed to be a genuine error, indicating undefined behavior or just a warning, so far I have been able to do everything perfectly fine with this message printing to the console every time I send a MIDI message, so it seems to me it's more of a developer warning rather than an error, but please correct me if I'm wrong.

If I am correct I think it would be better to replace the code here:

    // As long as we haven't reached our queue size limit, push the message.
    if ( !data->queue.push( message ) )
      std::cerr << "\nMidiInAlsa: message queue limit reached!!\n\n";

with something similar to what's found elsewhere like this:

#if defined(__RTMIDI_DEBUG__)
    // As long as we haven't reached our queue size limit, push the message.
    if ( !data->queue.push( message ) )
      std::cerr << "\nMidiInAlsa: message queue limit reached!!\n\n";
#endif

This matters because users of my library may be confused (as I was) about the severity of this error, but more importantly because it floods the console output when debugging.

I would make this change myself but I'm unsure about whether this is intentional behavior and I'm just missing something but also because I'm not very comfortable with C++.

Specifications like the version of the project, operating system, or hardware.

Release 4.0.0 built as a .so library librtmidi.so for linux-x86-64 with ALSA and JACK installed.

You can see the .so here: https://github.com/basshelal/JNARtMidi/tree/e3a761aa98a915dc1c8b98a3c6be08f94a72292d/bin/linux-x86-64

Many thanks for your efforts
😊

[radarsat1]

Sorry, I know this is old. Anyways, the message you mention should only be emitted if the queue gets full, and then there should be dropped incoming messages, so it's a bit strange that you say that the software continues to work as expected. This should only happen if MidiInApi::getMessage is not called often enough.

I do agree that that message could be reported differenty than just printing to cerr.

I had a quick look and it seems to me that the Java wrapper does not implement getMessage, so maybe that explains it? But then I am really confused how any incoming messages are working at all.

https://github.com/basshelal/JRtMidi/blob/e3a761aa98a915dc1c8b98a3c6be08f94a72292d/src/main/java/com/github/basshelal/jnartmidi/api/MidiInPort.java

    public double getMessage() {
        // TODO: 17/02/2021 Implement!
        return 0.0;
    }

[basshelal]

I haven't been working on this and won't be for some time but I still think it would be useful to have some different way of handling errors like this.

ALSA and JACK use callbacks for errors and provide nice convenient functions for those callbacks like this:

typedef err_cb_t (void *)(void);

/// pass NULL to reset to default, which prints to stderr
int set_error_callback(err_cb_t error_cb);

/// empty callback that does nothing, pass this to `set_error_callback`
err_cb_t get_empty_callback(void);

This is a little overkill I know but allows custom handling by clients if they want it.

Otherwise, I think a flag to toggle stderr on or off is an absolute must because in release scenarios having the stderr flooded with RtMidi messages is undesirable.

Whether that's by use of some macro (like I did in my PR #244) or better, by use of some actual flag that can be modified at runtime easily.