Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
basshelal opened this issue Feb 23, 2021 · 2 comments · May be fixed by #244
Open

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

basshelal opened this issue Feb 23, 2021 · 2 comments · May be fixed by #244

Comments

@basshelal
Copy link

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
😊
basshelal added a commit to basshelal/rtmidi that referenced this issue Mar 27, 2021
@basshelal
Surrounded all std::err calls regarding message queue limit reached w…
97166e2 
…ith a #if defined(__RTMIDI_DEBUG__) in order to prevent console flooding when message queue limit is reached, this fixes the issue I filed here: thestk#236
This was referenced Mar 27, 2021
Open
Open
@radarsat1
Copy link
Contributor

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
Copy link
Author

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.

@juxibuz juxibuz mentioned this issue Dec 17, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@radarsat1 @basshelal