#1750 kernel: sound midiC1D0: rawmidi drain error (avail = 4086, buffer_size = 4096)

[musewhirl]

I get a drain error on both debian bookworm and trixie. Is this generally reproducible? It boils down to whether RG should affect other applications using MIDI when it quits? It might be expected behavior if it's acceptable for RG to have exclusive use of a MIDI port.

Requirements

• In this case I used debian trixie
• An RG MIDI session about 30 secs
• A MIDI file composition about 30 secs (you'll need to wait for it to complete)
• ALSA command: aplaymidi

Steps to reproduce:

Preliminary

1. Launch RG
2. Open the MIDI session
3. In Manage MIDI Devices check the MIDI port RG is using e.g. 20:0
4. Open an OS terminal
5. Prepare the command: aplaymidi -p 20:0 simple.mid

Scenario 1:

1. Hit play in RG
2. Once RG is heard playing, hit enter in the terminal to start simple.mid
3. Both MIDI compositions will be heard together
4. Now, CTRL-C in the terminal to quit simple.mid and simple.mid stops
5. RG continues playing and is unaffected by the fact that simple.mid quit
6. Now hit stop in RG
7. Check the journal logs and there should be no drain error

Scenario 2:

1. Return RG to start of composition
2. Hit play in RG again
3. Start simple.mid again
4. Both are heard playing
5. Stop RG
6. Quit RG
7. simple.mid is no longer heard, but its process is still going
8. Wait for the 30 secs i.e. for simple.mid to reach its end

As soon as simple.mid ends, the following error appears in the OS logs:

kernel: sound midiC1D0: rawmidi drain error (avail = 4086, buffer_size = 4096)

On launching RG again, I think I actually hear the last notes from simple.mid(?). Were they the last down the drain?

Is this expected behavior i.e. RG needing exclusive use of the MIDI port?

[Ted Felix]

Maybe rg is a bit overzealous when closing connections.

Is the "process to reproduce" above something you are actually doing to try and create music? Or is there something different you need to do like using Ardour for some MIDI tracks and rg for others? Just want to get a feel for the actual use case that leads to this problem if it is different from the above.

[musewhirl]

Very good question. This bug is a stepping stone to gather information on how to tackle bug [#1732] ...and that probably answers your question as to the scenario. However, that would not be sufficient for readers who get this error in their own scenario should it arise. So, a bit more. This drain error is even hard to locate using a search engine although I have provided some. Quoting from way back in bug [#1732]:

But I would like to first know how to "cause" this buffer drain error intentionally.

You (@tedfelix) had already indicated that you could not actually reproduce the RG frozen screens in that bug and that was understandable. It's rare, but often enough to be annoying and reproducibility even defeated me who experiences it..

So, I found a way to reproduce it. It involved RG again in simpler scenario. And rather than the complexities of another major client like ardour and its own MIDI setup, I even simplified everything by using the command aplaymidi which only uses the MIDI port so that you can indicate whether you can reproduce this drain error. Quoting again from bug #1732 (to save you having to re-read the whole thing):

Unless RG is mishandling a low-level resource in some way, then something else is causing that error, which then appears in RG as a freeze and affects the keyboard i.e. ALSA/USB interface.

Do you know anything about that error and how it might relate to RG?

I received no answer. Perhaps you missed it seeing as that thread is definitely long...or perhaps you simply don't know, which is fine. So, this bug is to find a way for you to confirm whether you can reproduce this drain error which I consider the first stepping stone? Hence as per this bug description:

So the important question in this particular bug is whether you can reproduce this drain error?

Just reproducing it will not resolve bug [#1732] per se. But you may be able to track the cause or after-effects of the drain error which might help with my continuing bug #1732. And besides, it's not unreasonable for users to ask whether other MIDI applications can use a MIDI port that RG has seen, since it searches for them all on opening. Actually, the issue only occurs if the user later closes RG...that's when the other applications will realize something is up. Exclusivity to ALSA components may not be unusual. I think that jackd demands exclusive rights to its audio interface so the interface can't be dragged of while its standing on it. I suspect that ardour MIDI (not audio) or any MIDI client may run into the same issue.

But that is not my main concern here...bug [#1732] is. And I planned to write a follow up there once I got a answer on both drain error reproducibility and MIDI port exclusivity. BTW: I am not sure how to relate two bugs using source forge else I would have.

1. If exclusive, then for this is new bug, aplaymidi had no right to be using RG's MIDI port even if RG did not lock it down somehow. End of story.Then we can close this bug.
2. If not exclusive, the RG should not affect other applications using the port when it closes and the bug needs to be fixed

Then we can close this bug, and [#1732] will continue with the following characters:

• ALSA MIDI (in particular)
• Debian trixie (some other component no mentioned here)
• JACK audio
• USB audio interface (generally, not just mine)
• Keyboard (generally, not just mine)

With the upgrade from bookworm to trixie it looks like debian is off the hook. So, I will have to make my own assumptions concerning bug [#1732]. To reduce baggage here and answer your scenario request, a quick summary which is ultimately is all about [#1732]:

I use a scripted command line version of RG to open a session directly. When done, I kill RG and the next command line in the script opens the next RG session. I already suggested a feature () which might do this more cleanly, but for now I have to make do with this. I suspect that even though I have gone to great efforts to ensure that an RG instance is killed and definitely gone, the subsequent RG instance first freezes when opening, then behaves like aplaymidi i.e. it appears to be working although no MIDI reaches the keyboard AND when that instance of RG is closed, it results in the rare drain error. This only happens on rare occasions though, so I wondered if there was some timing issue which caused RG to snooker itself i.e. a previous RG instance affecting an opening of a new RG instance because the previous had assumed exclusive rights to the port? And even more quotes from [#1732]:

So it looks like the issue is in AlsaDriver::removeAllDevices(). The only thing this does is a snd_seq_delete_port() which does do some waiting until all port accesses end. This might be where we are getting stuck.

If so, then I would go further and suggest that since I actually added code to wait for the RG process to close, it's worth checking that AlsaDriver::removeAllDevices or a related command is not completing the request in it own timing i.e. perhaps occasionally finishing long after one instance of RG has closed and another is opening....And hence the latter ends up like aplaymidi's problem.

All supposition until I get some more facts, but I hope it covers everything.

[musewhirl]

I finally made some progress which also explains why you may not be able to reproduce the original error in bug #1732 or even this bug for that matter. It all boils down to the real trigger of the drain error. Both rosegarden and jackd normally work fine together with two separate keyboards (both Yamaha) used for testing except for occasionally with one keyboard. Simplifying the scenario by first removing jackd then even removing RG and just using aplaymidi with the keyboards was where I noticed a difference.

• Keyboard1 uses an external USB audio interface
• Keyboard2 uses an integrated (internal) USB audio interface

They were used separately for this test and Keyboard2 has all of the issues:

Keyboard1:

• aplaymidi alone works fine
• aplaymidi + RG (no jackd): Opening and closing RG has no effect on aplaymidi, and hence no drain error
• aplaymidi + jackd without -X option (no RG): works fine.
• aplaymidi + jackd -X raw: An expected error - Cannot connect to port 20:0 - Resource temporarily unavailable
• aplaymidi + jackd -X seq: works fine

Keyboard2:

• aplaymidi alone appears to be playing, but there is no audio from the MIDI sound module. If fact, no messages actually reach Keyboard2. After aplaymidi composition time passes, the drain error shows up in the kernel logs.
• aplaymidi + RG (no jackd): When RG is open (or even multiple instances), aplaymidi works, but when the last instance of RG is closed it stops. RG did not stop aplaymidi working...in fact it only worked because RG was open, which is odd
• aplaymidi + jackd without -X option (no RG): No sound and on ending a drain error.
• aplaymidi + jackd -X raw: Same error as other keyboard - Cannot connect to port 20:0 - Resource temporarily unavailable
• aplaymidi + jackd -X seq: works fine, which was unexpected.

All these facts are reproducible every time for each keyboard. Hence, if aplaymidi works with all your keyboards as in Keyboard1, it's possible you won't see what I believe is the related RG frozen screens with that drain error at the end of the composition. This implies it's down to Keyboard2 and its firmware, which being an internal USB audio interfance, I obviously cannot do anything about.

So, I've been using jackd -X seq with its MIDI ports that I don't even use in the original scenario #1732. I am waiting to see if RG still freezes and then itself ends with the drain error. Perhaps because aplaymidi did not experience it, RG may not either since draining is handled somehow?

No problems so far, when normally it would have by now. Of course, it's taken ages to randomly appear previously. There was one new error which showed up in jackd logs while one instance of RG was closing and another opened...i.e. just about the time when a freeze would occur. But neither RG nor my keyboard froze:

jack_midi_event_reserve: time parameter is earlier than last reserved event

No idea what that means and it may be unrelated. But just like the case of freezing it only turned up once out of the blue after using -X seq and I've not seen it before. I will continue with this jackd option to see if RG still freezes followed by its own drain error. After that, all that remains is to close out the bug as being outside of RG. In the meantime, as far as I can tell, there is nothing for developers to do.

[Ted Felix]

Maybe Active Sensing (FE) is the culprit here. Maybe one of your keyboards is sending out active sensing and that's flooding the buffers. I think my DX-7 does this. I'm guessing older keyboards would be more likely to do this. The transport window IN/OUT fields might show this.

[musewhirl]

You hit the nail right on the head!

I'm not familiar with the term Active Sensing, but in the past I've tried aseqdump on that port and always got back a constant stream of Active Sensing and Clock output and just assumed it to be normal behavior. The keyboard is barely a couple of years old and so could be considered modern, and has operated perfectly in virtually every way with RG, JACK and Ardour. The only issue I've had is in the specific scenario of bug #1732...and rarely too. And that "only" started happening with using command line RG to launch and killing it without using CTRL-Q, which I never did before.

Funny enough, while aseqdump was running I noticed that aplaymidi worked too. But I don't want aseqdump around, or anything else unnecessary while my OS is keeping "real time". But since jackd is always running and the -X option does not appear to hurt anything, I can live with that.

Since my last post I realized the obvious fact that I could temporarily bypass the integrated keyboard by using an external audio interface plus direct MIDI i.e. the same setup I had for Keyboard1. Normally this does not work for me since the integrated USB interface handles more audio channels than I can get with that external audio interface.

But since you now mentioned it, I went back and tried it and bingo....not a single Active Sensing or Clock output :-) And of course, aplaymidi works just fine even for what had become the problematic keyboard. Alas, I can't use it that way but with regard to the cause of the rawmidi drain and subsequent silence which occurs even for RG in bug #1732, this has got to be it.

I also opened a support ticket previously for the keyboard describing the situation. I specifically asked if there is some setting in the keyboard which would fix the issue and am awaiting a response. Now I can mention Active Sensing, which they should more easily understand.

I've also been trying to find out which buffer the drain error was talking about. Presumably, if the buffer was just too short I may be able to change it in Linux so long as it does not short change JACK audio real time.

And I've still not had the #1732 issue since using the -X option. By the end of this week, I will probably add that to bug #1732. It won't work generally for RG users who don't use JACK though, but the clues in this bug should be sufficient to alert them to what's going on should they encounter it.

Thanks. That was very useful info.

[Ted Felix]

Maybe you can turn off Active Sensing (FE) and Timing Clock (F8) at the keyboard?

I think ALSA is wrong to buffer those. Since they come in constantly, it should only "buffer" the last one maybe in their own separate buffer. So long as some app is paying attention, it shouldn't be a problem. I see this as mainly an ALSA issue.

[musewhirl]

I did find and turn off the Clock Out yesterday, but I could find nothing about Active Sensing anywhere and was using search engines, before posting back.

It seems Active Sensing is a bone of contention, at least according to search engines, with one portion all for disabling it or at least having a way to do so. At yamahasynth the phrase only turns up a half-dozen times (a bit surprising) and someone stated not only is it part of the MIDI spec (with Yamaha being a founding member), but furthermore:

The MIDI spec saying it's optional means devices do not have to have it in order to be compliant with the MIDI spec - not that devices that have it need to have an option to turn it on or off.

which is a quote from: https://yamahasynth.com/community/moxf-series-music-production-synthesizers/how-do-i-turn-off-active-sensing-on-my-moxf6/

That even lets ALSA off the hook. I doubt Yamaha support will be able to resolve that for my keyboard. However, at least now my attention has been drawn to it. The Clock Out was flooding the same port buffer and at an even more frequent rate. Without it, I only get the 250-300 sec hit eating into my JACK audio "real time", assuming that something in the OS, apart from the buffer, still has to deal with it.

Oh..and a correction to my last post which is interesting. When I said that there is no Active Sensing/Clock Out for the external USB -> MIDI cable -> keyboard, that was only partially true. Since I was only using aplaymidi, I only connected one MIDI cable for the test i.e. to MIDI IN of the keyboard. It occurred to me that I had not really done the test properly, so I connected the other cable to be complete....and all of a sudden the flood of Active Sensing/Clock Out. Remove it and it stops. Weird. That is one way to turn it off i.e. if one is not recording actual MIDI AND one is using a true MIDI cable to the keyboard. However, for the integrated USB MIDI route you can turn off both MIDI IN and OUT via the menu options, but you can't turn off just one :-( For the life of me, I can't see why Yamaha would have done that! Otherwise the problem would be resolved.

Well, although it's well out of the RG scope now, I will take a brief look at ALSA configuration file syntax to try and override their helpful initialization for general MIDI devices. If I can find the of equivalent making the MIDI record appear not to be there, then maybe the keyboard will refrain from flooding the buffer...at least when not recording MIDI. It's a long shot, and ALSA syntax is a bit complex. But it's worth a brief look at least.

[musewhirl]

I think we can close this issue because although RG experiences the rawmidi drain error on rare occasions, it is not the cause. In fact, when it is open, along with other MIDI aware applications, that may be why the buffer is drained sufficiently most of the time. Even using only aseqdump on that port allows aplaymidi to work with the problematic Keyboard2 USB adaptor. As for the theory that Active Sensing (and Clock Out) may be flooding the buffer, I arranged for that to occur using a different USB adaptor and aplaymidi still worked on its own. But I still feel that Active Sensing flooding is involved in this issue all the same, and unfortunately there is no way to eliminate it from the problematic keyboard.

On the bright side, since using jackd with the -X seq option, RG has not frozen once or experienced the rawmidi drain error. I am convinced that the setting fixed it, since it would certainly have happened by now. But I'll have to find a different technique since unfortunately that -X seq option comes with its own problems...not for RG, but ardour complains on start up about being unable to communicate with some thread or other. Even though ardour appears to work after that, I don't like that error being around any more than the rawmidi drain. Next, I intend to try always running low resource aseqdump in the background instead, and only when needed when using that particular keyboard USB adaptor.

Feel free to close.