#1732 Rosegarden takes 10-15 secs to open a session and same to quit

[musewhirl]

RG itself starts up just fine, but on attempting to open any session the delays shown below occur for both opening and closing that session. This has happened only once before about a month or so ago.

As to how to reproduce this, that's not clear. This particular occurrence happened when a Lilypond preview PDF was opened. The session then sent no MIDI to an external keyboard alerting me to something being wrong. Previous sessions were working fine. NB: That same session has worked flawlessly, including Lilypond preview, even the day before. This session may only have been a trigger for the scenario, unless something else occurred just prior to it. Once the problem begins though, it occurs no matter what you are doing with RG after that...including closing and reopening.

Opening a session:

[StartupTester] StartupTester::StartupTester(): URL:  "http://www.rosegardenmusic.com/latest-version.txt"
[StartupTester] StartupTester::slotNetworkFinished(): Connection failed:  "Host www.rosegardenmusic.com not found"
...
10-15 secs
...
[AlsaDriver] renameDevice(): WARNING: Cannot find device  0  in port map
[Composition] dtor: WARNING: 4 observers still extant:

Closing a session:

[main] Rosegarden main() exiting with rc: 0
...
10-15 secs
...
[AudioPlayQueue] dtor...
[AudioPlayQueue] This tends to be the last thing you'll see on a normal exit.

[musewhirl]

All the following fail to remedy the situation:

• Open different sessions
• Uncheck all preference check boxes referring to JACK
• Restart RG...even tried some earlier old versions of the master...all exhibited the same problem
• Restart JACK (with check boxes since it didn't matter), then restart RG
• Shutdown the computer, start JACK and start RG

The last one just didn't make sense, unless RG maintained state some place I didn't know about...but there you have it.

Staring at this strange scenario, my eyes drifted to the external keyboard, quietly sitting there apparently doing nothing. It was still on and attached to the computer via USB, and that was the final clue. The only thing which worked was to include the shutdown the external keyboard. Then after restarting everything, sessions opened normally again. But I did see one difference in the logs where that lost time occurred:

[main] Rosegarden main() exiting with rc: 0
[SoundDriver] SoundDriver::~SoundDriver (exiting)
[AudioPlayQueue] dtor...
[AudioPlayQueue] This tends to be the last thing you'll see on a normal exit.

That reference to ~SoundDriver was never showing up during the issue. I found the following in the code:

SoundDriver::~SoundDriver()
{
    RG_DEBUG << "SoundDriver::~SoundDriver (exiting)";

    delete m_audioQueue;
    clearAudioFiles();
}

1. Why would this debug statement not appear in the logs during the problem?
2. And since it may take time for the problem to reoccur, what do you suggest I try, if and when it does?

I should point out that during all of this, although ardour used the same JACK instance and the keyboard's audio interface for audio output only, it did not appear to be affected by the problem, but then again ardour was not using MIDI in that session.

[musewhirl]

This issue occurred again with a different session, and so has nothing to do with Lilypond.

A session was opened from the command line using the file argument. I could see RG had a number of windows on screen, but some were just outlines for the 10-15 secs. In other words, RG was frozen for that time. Then the session appeared to be normal except no MIDI is sent to the external keyboard...or so I thought. A check with aseqdump showed that MIDI is being sent by RG, so presumably not received by the external keyboard.

On opening any RG session, the kernel logs showed:
kernel: sound midiC0D0: rawmidi drain error (avail = 4022, buffer_size = 4096)

A similar entry on closing JACK after closing RG.

However, when JACK is started and closed alone, the kernel reports no error. Neither does it do so on just starting RG after JACK...only when a session is opened.

Rather than give up again and shut everything down like before, I stopped both RG and JACK and only removed and inserted the keyboard USB interface. Although registered OK by the OS, I noticed that the keyboard itself was unresponsive even after removing the USB (didn't notice last time), and required shutdown to recover.

My first instinct is that the state of the keyboard is a result of some interaction with messages from RG, since it's relatively new and shown no issues before now. These issues have only begun very recently and the only real change on the computer has been security updates and a few new RG masters. But that proves nothing.

The only search engine reference I see to this type of error anywhere is here:
https://www.alsa-project.org/alsa-doc/alsa-lib/rawmidi.html

It states:

Sync open (flag)

Using #SND_RAWMIDI_SYNC flag (output only) assures that the contents of output buffer specified using snd_rawmidi_write() is always drained before the function exits. This behavior is same like 'snd_rawmidi_write() followed by snd_rawmidi_drain() immediately'.

But I don't see RG doing anything like this in the code directly?

Modify MIDI Filters has lots of THRU messages to ignore, and I feel like leaning to the cautious side and ignoring just about everything. Perhaps the keyboard is unhappy with some of them and incapable of ignoring them itself? But I would like to first know how to "cause" this buffer drain error intentionally.

Any ideas?

[Philip Leishman]

Very strange.
Do you have Midi Sync activated (under preferences midi). I have always had that switched off.
Difficult to know how to narrow down the possibilities here.
Are there any plugins used in the session when the problem occurs ?

[musewhirl]

Yes...it will be difficult to debug. Just after reporting the bug, I went back to continue and it happened again. I had to shut everything down since the keyboard provides the audio interface, and both JACK and RG are tied to that.

I too have the MIDI sync turned off...in fact all off on that tab. I have no plugins in any of th sessions which were opened prior to and up to when the problem started.

There are two parts to the problem:

1. The trigger: So far unknown, but the order of the sessions opened is the same as when the problem does not occur...all I did was play them to their end and close them
2. Once the problem occurs, the behavior occurs even for a fresh instance of RG and for previous versions too. But perhaps that is all explained by the fact that the external keyboard has been affected in some way beforehand, either via the USB audio interface or one of its setting e.g. blocked reading an empty buffer synchronously. Removing and re-inserting the USB does not work either.

Well, with two shutdowns on the same day, I decided to just "change something". What I noticed is that the dozen or so sessions involved did have one thing in common, which I alluded to in the past post...the MIDI THRU filters were not ignoring any of those events for play or record. You (Philip) suggested in bug #1690 that ignoring certain events might help, and that worked out great there. I thought I had adjusted that setting for all sessions i.e. ignore everything by default, and turn them on only if needed. But I missed this particular set. And now when using this set, a mysterious problem where the keyboard itself freezes and does not even respond to any of its switches let alone the actual keyboard. It's not happened for any other sessions. Also note, those sessions have been around for years untouched, same keyboard, same OS and worked fine...so something else has changed.

I've now set all those sessions to ignore THRU events, but have to wait and see if this random bug occurs again...it took a week one time, and just an hour or so of use after the last post.

To be able to reproduce this, I would need information about the buffer error where "sound midiC0D0" tracks ALSA's /dev/snd /midiC0D0. But how is that buffer size of 4096 set? Once we have control of that buffer size, it might be possible to adjust it force the problem out of its apparent randomness.

[Ted Felix]

If you can repeat this fairly regularly, you can try running rg in gdb, causing the delay, then pressing Ctrl+C in gdb to stop rg when it hangs. Do a "bt" to get a backtrace. That should tell us where the issue is. rg has multiple threads, so it might be a little trickier than this, but it should be doable. Let me know if you need more info.

[musewhirl]

It's not predictable yet. But after it occurs, any RG instance opened is affected, so yes using gdb during that launch could prove very useful for the freezing part. However, I generally do not keep development tools on the box in question, although if the problem occurs I can install it for that time...only MIDI is affected during all of this.

I can probably figure out the steps but the bug bound to catch me out in the middle of a session. So, assuming that gdb and its dependencies are around AND any attempt to open an RG instance freezes, what are the exact steps I should take before starting RG in that scenario? Armed with that, I will revert all of the sessions back to using THRU, assuming that has anything to even do with this, and wait out the bug.

[Ted Felix]

You'll want to use a debug build for this. I assume you are already running debug builds to get debug output, so you should be ok.

Run rg with gdb like this:

$ gdb build/rosegarden

At the gdb prompt:

(gdb) run

(gdb might ask some questions about debuginfo. Just say no.)

rg will start as usual. When it hangs, switch to the terminal where gdb is running and press Ctrl+C. From here you can do a backtrace (bt)

(gdb) bt

and look at the threads (info threads).

(gdb) info threads

Use the "t" command to select a thread and then bt to get the backtrace

(gdb) t 1
[Switching to thread 1 (Thread 0x7fffec386d00 (LWP 239834))]
#0  dl_open_worker_begin (a=a@entry=0x7fffffffb430) at ./elf/dl-open.c:781
warning: 781    ./elf/dl-open.c: No such file or directory
(gdb) bt
#0  dl_open_worker_begin (a=a@entry=0x7fffffffb430) at ./elf/dl-open.c:781
...

Since we aren't sure which thread is hanging, we'll need the backtrace from each thread.

Don't worry too much about missing file or name warnings. You'd need to load up the symbols for all the libraries, and that probably won't help all that much. We're more concerned with what rg was doing when it got stuck. That should tell enough of the story to figure out what's wrong.

Note that you can experiment with this when rg isn't crashing. Just Ctrl+C in the gdb terminal at any point during a normal rg session to get some practice with gdb.

Use the quit command to quit gdb.

[musewhirl]

I haven't had to use gdb for a long time, so your instructions are very helpful and clear. I decided to get the gdb install over and done with beforehand...it's pretty a light install. I also reverted all the sessions in question.

So, it's just a matter of waiting. I'm sure the gremlins noticed the gdb install, so there's a chance they're smiling and have head to ground to wait me out...you know how they are. But then again, they're always up for a challenge! :-)

[musewhirl]

So, I was right...the gremlins had plans of their own. No matter what I did, I could not get this bug to reoccur, even though I believe I've repeated everything as before every day since. I even tried slight variations just in case. Nothing. And it should have occurred by now.

Two things have changed, although it's difficult to know if they are involved:

1. After reporting the bug, I posted that I set those sessions to ignore "all" Midi THRU events to the keyboard. However, I recall that at least one of them ignored all except Note. The point is, I can't put them all back the way they really were. Now I have unchecked all boxes i.e. ignore no events across the board...but if it was some combo, then who knows.
2. Although unlikely, there was bug #1735 flooding the logs to the extent of hundreds of thousands over just a few minutes. I was running through those sessions for about an hour. Now if that's just logging, then it's just harmless disk space. On the other hand, if that tight loop involved communication with e.g. ALSA, JACK, the audio interface or the keyboard, then maybe that could have triggered a problem. Until the bug fix arrives, I had to change all of the sessions to have 4 audio inputs, even though they now only contain MIDI tracks, in order to silence the logs.

On the bright side, while doing something completely different, I did get RG to freeze, although you will see that not only is the scenario different, but the keyboard did not freeze, and I could still use MIDI after the 10-15 secs passed. In any case, gdb rode to the rescue as per earlier instructions in this bug thanks to @tedfelix, and I will post that next.

[musewhirl]

I wasn't even using the problem sessions at this time, just checking another audio interface. These may be steps to reproduce, but are just the scenario as it unfolded:

1. No RG instances were running
2. JACK is running with AudioInterface1 which is attached to my keyboard
3. I added another USB AudioInterface2. It is MIDI capable too, if attached to a keyboard, but had no cables attached, and I did not even start any JACK server for it...just plugged in the USB to use alsa-info etc.
4. I started RG normally and no freeze
5. I closed RG and restarted it using the command line with an rg file. Now it froze for 10 secs.
6. This was repeatable by removing the second interface and seeing no problem, then plugging it back in again

NB: When the bug was opened, no other audio interface was involved, but I was using the rg file method every time. Also note, that in that case, even opening RG normally froze, so it's not the same scenario, but I think you may be able to reproduce this one.

I followed the instructions provided earlier and hope they reveal something in the attached gdb output. One other total guess is worth mentioning, based on this and what occurred before. This extra audio interface does support MIDI, but I did not have any cables connected to it. In the previous scenario, when the keyboard itself froze (reasons for that still unknown), I assume that its MIDI was unavailable. RG did send MIDI when it finally opened after the freeze (checked with aseqdump), but the keyboard meter levels did not respond to MIDI and I heard nothing. At that time, I could hear audio sent by ardour to the keyboard. That may relate the two scenarios...an audio interface capable of receiving MIDI, but is not responding. Then RG freezes with frames around missing windows, and no clue as to what's going on. But that is pure speculation.

[Ted Felix]

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. Maybe some device is blasting us with inputs? Or rg is blasting some device with outputs at the time? Or something else?

I've added some diagnostics to the code. Instructions to enable:

1. Build and run the latest from git. [d9d5a3] or later. And close. This will create the "musewhirl" entry in Rosegarden.conf so it is easier to find.
2. Open ~/.confg/rosegardenmusic/Rosegarden.conf in your favorite editor.
3. Search for "musewhirl", set to true, save and exit editor.

Now when running Rosegarden, you will see output like this:

[AlsaDriver] removeAllDevices()...
[AlsaDriver]    "out 1 - General MIDI Device"  [ 0 , 3 ]
[AlsaDriver]       port deleted

In the future when it hangs, it should show a port name (like the "out 1..." above) but no "port deleted" as it is waiting for the snd_seq_delete_port() to end. This diagnostic serves two purposes:

1. Confirm this is where the hang is. A port name should be logged while the "port deleted" will take a while to appear. That confirms this is exactly what is hanging.
2. Maybe show exactly which port/device is hanging. Note the port name that hangs. What is unusual about the MIDI device attached to that port?

If this logging seems like it might be generally useful in the future, we should give it a more permanent location in the .conf, e.g. [Debug] alsaDeletePort=true.

[musewhirl]

I'll download the new master for the above instructions. In the meantime, since I always see the following in the logs even with no extra audio interface, I might as well ask what information this entry in the logs is trying to convey:

[AlsaDriver] renameDevice(): WARNING: Cannot find device 0 in port map

In the rg file itself, there is always a device 0 tag and mostly its direction is record:

<device id="0" name="MIDI input system device" direction="record" variation="" connection="keyboard" type="midi">

This entry appears even in sessions where I don't record MIDI...in fact, the entry shows up when starting rosegarden and has done so for all versions I can recall. Is that normal? Seems not, or why else the warning.

And for the question of what is unusual about the MIDI device attached to that port? Quite frankly nothing that I have not mentioned already...it only occurs when the second audio interface is added as described below:

1. RG, its autoload studio, and the session are all set up for the normal audio interface which happens to be part of the keyboard i.e. the MIDI is always available
2. The second audio interface was not even to be used with RG...its USB was merely plugged into the computer USB port and then RG was started
3. Its USB audio interface is MIDI capable, but it is just an audio interface...a MIDI cable to a separate keyboard needs to be attached to it
4. However, what seems significant at this point is that when RG froze, no cables i.e. no MIDI was available to that audio interface.

You should be able to reproduce that if you have any audio interface around, which you would normally use to connect a computer to a MIDI device. Just plug that in after your normal audio interface (i.e. two interfaces just to match this scenario) and make sure that you don't have a MIDI attached. Then start RG. If it hangs, then the scenario is confirmed. If not, then sure...something local is going on here

[Ted Felix]

[AlsaDriver] renameDevice(): WARNING: Cannot find device 0 in port map

This message is issued at file read time when we are reading a device tag. I added the name to the logging and it appears to only happen for input ports. Those are created elsewhere and named some variation on "record in".

It's a harmless message that can be ignored. It should probably be suppressed for input ports since they are created in a different manner.

[musewhirl]

OK...results. Well, it's not news. Rosegarden freezes exactly where you thought it would:

[AlsaDriver] removeAllDevices()...
[AlsaDriver]    "out 1 - Keyboard 1"  [ 1 , 2 ]
...
10 seconds with just window outlines
...
[AlsaDriver]       port deleted

Why removeAllDevices? Then it occurred to me. An important requirement of this freezing is that RG is first opened, which it does normally i.e. no freeze. But then you attempt to open another session, and the current one (even the autoload studio) is closed, leading to a removeAllDevices.

Requirement 1:
This scenario is most easily achieved by supplying the target rg file via the command line. RG first opens the default studio, and then closes that to open the target session.

But that is not enough, and at this point, I still don't think it's local issue of either interface. Both work normally on their own. This is what I did next, since it's reproducible here:

Setup:

• Audio interface 1 is part of the keyboard, so below it's referred to as "Keyboard 1". When plugged in MIDI is always available.
• Audio interface 2 has USB into it (connected to the computer) and MIDI port out the back but without keyboard attached. I'll refer to it as "MIDI Out 2". It's looking like it does not matter whether the MIDI port out is connected...but I can't confirm that.

Steps

1. I eliminated JACK from the equation. i.e. no JACK server to either interface.
2. Connect Keyboard 1 USB only, command line open three times (different rg files) and no freezing. MIDI works fine when sent via USB.
3. Disconnect Keyboard 1
4. Connect MIDI Out 2 USB only, command line open three times (different rg files) and no freezing. MIDI works fine when sent via USB and passed on by its MIDI out port connected to the keyboard
5. Remove MIDI Out 2's connection to the keyboard via MIDI cables to simplify the picture
6. Disconnect both USB interfaces.
7. Connect Keyboard 1 followed by MIDI Out 2, command line open and no freezing on the first or second go, but by the third RG freezes for 10s and log contains the above entry
8. Disconnect both USB interfaces.
9. Connect MIDI Out 2 followed by Keyboard 1, command line once and RG freezes for 10s immediately and log contains the above entry

All repeatable, except that when first setting up or even leaving the computer unattended, it does take about three openings before the freeze cuts in. After that, it freezes first time, every time.

Requirement 2:

Both interfaces need to be present, and freezing only occurs after RG starts normally and another session is opened manually, or the same thing in one step via command line.

Two things does bother me though

1. A slight asymmetry which might mean it's just a local keyboard issue. When I reversed the order of connecting the interfaces, I expected the log entry to mention MIDI Out 2...but it didn't. It stuck with Keyboard 1, although that in itself is not conclusive of anything.
2. The other point is that the second interface was never intended to have anything to do with RG. I just plugged it in temporarily to read its interface data...but we will come back to that when/if we get some idea about what's going on.

I mentioned in a previous post that connecting the MIDI cable to MIDI Out 2 to an available external keyboard might be a factor. Well, I did try to connect to MIDI Out 2 to the MIDI in of Keyboard 1 when both USB interfaces were present. However, the keyboard can only accept MIDI from either the USB interface OR via its MIDI ports. So with both interfaces connected, there is always one that will not get access to the keyboard even though RG thinks it has. Therefore RG could still freeze because it did not get a timely response.

So, you have all I know in order to recreate a similar scenario unless you want to add more debug statements.

[Ted Felix]

Since the hang is happening way down in ioctl() calls in the device driver, this feels like an ALSA and/or driver issue. Or maybe a hardware issue. I tried to reproduce and could not.

I used an M-Audio MIDISPORT Uno for the MIDI interface and a Yamaha MM-6 for the keyboard. Followed your procedure. No delays at any point. I'm running Linux/ALSA 6.14.0 from Ubuntu (6.14.0-29-generic).

General USB troubleshooting... I've had trouble with MIDI devices plugged into USB3.0 ports. Try using different USB ports on the machine. Avoid the blue (3.0) ones, stick to the black (2.0) ones. Use different USB cable(s).

Do you have a third MIDI USB device? If so, try mixing it in with the others:

1. 1 (keyboard) and 3
2. 2 (MIDI interface) and 3

That might point to either 1 or 2 being the specific culprit that doesn't get along when combined with others.

[musewhirl]

Your suggestions make perfect sense. And the fact that you can't reproduce it is useful too and points to something at my end.

Funny enough, your mentioning MIDISPORT reminded me that I have a USB MIDISPORT 2X2 lying around somewhere in a box, which I've not used in over a decade. I'll dig that up and it will settle everything. As for trying a USB 2.0 port, unfortunately all four of my ports are the blue USB 3.0 type...a sign of the times.

But remember that with those same USB ports, on its own, the keyboard with built-in audio interface works perfectly with RG. And the other audio interface, when connected to yet another keyboard (in storage, and hard to get to), worked perfectly with RG too. Both, independently, can play and record with no issues. So, it can't be the cables, port types, audio interfaces or equipment as such. It's only when "both" USBs are plugged in that RG freezes. And although JACK is known for audio, I can connect two different JACK servers to the audio interfaces when they are both plugged in, and JACK starts up, listens on each independently and reports no issues on either. Then again, it's not trying to do anything with MIDI. Ardour is also MIDI aware and it launches and quits without freezing, but I've not used its sequencer in years. In the end, it might well be what you suggested i.e. an ALSA issue after all.

In the mean time, I'll address the second point in my last post which bothered me a bit, as I so quaintly put it. This bug would not have occurred if RG hadn't noticed the other audio interface, which I had plugged in for an entirely different purpose. So, RG is freezing up when apparently trying to deal with an audio interface which I didn't want it to have anything to do with. Dredging up my post in bug #1686 (yeah...over a year ago), I'll paste the relevant part here to save you time:

During all of this, you will note that on a restart of RG, even a fresh install, it will jump on aseqdump MIDI receiver, if it's the only MIDI port. Unfortunately, I think RG may still grab that port even if the real keyboard ports are there beforehand. How would it know it was different?

I guess to make life simple for first time users, it must be seeking out any MIDI interface and adding to its device list, as evidence by the fact that both of the audio interfaces are shown in the Manage MIDI Devices window...aseqdump would show up there too if running, albeit with the word write in parenthesis when I saw it last. Then all may be subject to that removeaAllDevices, when that should only apply to the ones that RG has jurisdiction over.

Has another approach, which I find cleaner, been considered? What I suggest follows:

1. Fresh install of RG
2. Launch RG and up pops a window, No MIDI devices. Would you like to scan for one? That, along with a big button labeled SCAN
3. Normally, there is only one around, so a newbie picks that, and they are off. They also know about scan too.
4. If a new device is added meant for RG, then it's back to the Manage MIDI Devices window hit Scan again and choose it

Now there is no guessing what the user wants to use. They keep their default MIDI device in the autoload studio, and can scan for and keep other devices in the sessions in which they need them.

And of course, in my scenario RG may not have frozen, assuming (big assumption) that if RG didn't know about the other audio interface this issue would not have occurred. I would not have cared, because I had no intention of using that temporary interface with RG anyway. And seqdump instances galore would not show up in RG uninvited. It's just a thought or two. Comment?

Anyway, I can't wait to do that "divide and conquer" test you suggested. I'll return with the results of the MIDISPORT permutations test.

[musewhirl]

There are complications due to apparent randomness in the results. At first, swapping in the MIDISPORT as the second interface appeared to avoid the bug. I nearly sat down to report that after an initial 10 starts trouble free. But somewhere along the line rosegarden froze with that too. But only once. I then repeated it a dozen more times and no freeze. At least that never happens in the real scenario...there, it's repeatable first time, every time. I did track down one source of the apparent randomness. It involves what I mentioned in the last post i.e. RG seeking out all MIDI devices on launch and adding them to its list.

1. Although not certain, I think the Manage MIDI Devices list order depends on the order in which the MIDI devices are added to the computer...possibly the order in which ALSA discovered the hardware. I'll have to check that and hope it's not random as I unplug all and plug them in again
2. Add to that the fact that RG has internally been told, per last time the session was saved, which MIDI device to prefer from its list
3. This is complicated by the fact that if that device is not in the list, then it selects the first one (I think) in the list of any device out there
4. That first one failed for me because I happened to use MIDISPORT's port B...and that was not first. So whatever MIDI interactions occur on start were not even happening...not even a sound of the the keyboard. I switched to port A after that.
5. And for complications on complications, this bug scenario involves launching RG first, which never (I think) freezes on launch, but freezes when opening the next session (as with rg file on the command line)
6. That means, the autoload studio uses its preferred device if available AND the second session uses its preferred device if available, and either will simply select another one out there otherwise.

The only thing certain for the reported scenario is that at least the default studio and the session chosen do have the same preferred device. But I've been thrown for a loop so far because I've been plugging and unplugging the various audio interfaces, and when the preferred device is not available, RG picks one of the others that happens to be first...and that is not necessarily this scenario...it just increases the possibilities of apparent randomness. Now I'm unplugging all of them and adding them in a fixed order to match the original scenario.

It's too early for conclusions, but it's beginning to feel like it might still be an issue with the keyboard via the USB interface, not the keyboard itself. The MIDISPORT is connected directly to the same keyboard via MIDI cables so I will be able to take the keyboard interface out of the equation. The only way to prove that is to alter the autoload and second session preferences to be MIDISPORT so that at least is fixed, and use the third audio interface to create the two interface scenario.

[musewhirl]

I can't seem to get RG to play along with creating this scenario with a new MIDI device. The problem is its handling of multiple MIDI interfaces. What I noticed is the following:

• I only add one audio interface e.g. MIDISPORT
• I open RG and it is the only device in the MIDI devices window. I save that default studio
• I create a new session. It too only shows MIDISPORT. I save that session too.
• I check both rg files, and neither is updated with MIDISPORT as the connection.
• The autoload still has the previous keyboard, as does the new session?

Question: Does that happen in your case?

• I close RG and add another MIDI device to the computer.
• I leave the MIDISPORT added to the computer i.e. two devices
• When I open up the default session and the other session, both now have the newly added MIDI device selected in the Manage MIDI devices window. In other words, MIDISPORT is no longer the one selected as it was when last closed, even though attached. It's in the list though.

Question: Does that happen at your end?

You can try keeping the MIDISPORT constant and adding any other MIDI devices you have around, and the question is does MIDISPORT remain selected regardless? If not, how is RG deciding which device to pick "for the user", if it's not using the one in the rg file and has multiple in its list. It's not the first in the list either from what I've seen.

Finally, how do I tell RG to use only the device I specify, and if that's not there then go to "No Port"? I get the feeling that can't be done though :-) This feels like bug a rehash of bug #1687.

[musewhirl]

Finally, I found the DNA of this bug :-) It's simple, and I think I can get you to reproduce it easily. Right now, I can now turn it on and off like a light. I had the advantage because of its repeatability at my end. And it is in fact a rehash of bug #1687 as mentioned in the last post. You'll need circumstances of that bug, which basically is a summary here:

When I first used RG, I had AudioInterface-1 and RG started with a default studio rg file field with: connection="" for play and record. And so that remains unless the user actually opens RG with a MIDI device and saves that session as the new default studio, which is what I did. So, my default studio rg file contains:

<device id="0" direction="record" connection="20:0 AudioInteface-1 (duplex)">
<device id="1" direction="play" connection="20:0 AudioInteface-1 (duplex)">

These connections appeared in the Manage MIDI Devices window and was the same for all sessions created using that default studio. Then time to retire AudioInterface-1 in favor of Keyboard-1. So now the default studio still has the entries above...no way to change that except manually as far as I know. But, new session rg files contain the following since only the new interface is plugged in:

<device id="0" direction="record" connection="20:0 Keyboard-1 (duplex)">
<device id="1" direction="play" connection="20:0 Keyboard-1 (duplex)">

Somewhere over time, perhaps while debugging bug #1687, the default studio's play device became that of the new keyboard, so it's rg file became the following i.e. the connections do not match. I suppose there is nothing wrong with recording from one interface while play to another, but that was not my intent:

<device id="0" direction="record" connection="20:0 AudioInteface-1 (duplex)">
<device id="1" direction="play" connection="20:0 Keyboard-1 (duplex)">

All new sessions created since then, inherited these mixed settings, even though AudioInterface-1 was never plugged in. And to date I have not detected any issues until I resurrected the old AudioInterface-1, not to use, but just plugged it in. Somehow, that removeAllDevices() is adversely affected by the mismatch which leads to RG freezing. This is the key to the issue when both interfaces are plugged in:

• If I change the record connection to Keyboard-1 to match that of play, no freeze...mismatch them, instant freeze.
• If record connection is empty, no freeze
• If both play and record are empty, no freeze.

And don't forget that it involves not just starting that studio , but opening another session (not sure if the added mismatch of the latter plays any role).

Going back to the inability, as far as I know, to get RG to empty that connection string or keep it up to date, I will have to do that myself manually i.e. set both record and play to empty once and for all in the default studio. Then sessions created from that will have identical connections for their play and record based on whatever device happens to be around.

Allowing the original interface to remain in sessions indefinitely, with no way to change them, is probably not a good idea, in case some unexpected circumstance or dependency turns up like the current scenario.

See if you can reproduce the bug this way and let me know. Is it a bug, or just misconfiguration i.e. are users allowed to pick different play and record connections anyway?

[Ted Felix]

This is very perplexing. The hang is being caused by the initial clearing of connections before we read the .rg file. So the contents of the .rg file can't be causing the issue. Unless the .rg file is loaded twice. Then it will only happen the second time. Unless you have the same setup in your autoload.

Can you send me a screenshot of the "Manage MIDI Devices" window prior to the load that hangs? This will give me an idea of what removeAllDevices() is actually starting with which can be completely different from what is in the .rg file.

[musewhirl]

Yes...it's troublesome and I have not completely given up on it. I tried a few things since and it's only occurred once since the last post over a month ago. I even thought it had gone. Then wham! "Did you miss me?"

My last post about the "DNA of the bug" described how to duplicate the issue every time but not via normal RG usage. It can be done using your own OS, two audio interfaces to your own keyboard, one of which was a MIDISPORT which you mentioned.

• Did you reproduce it?

If not, then:

1. It's my keyboard OR
2. It's my version of the OS

If (1), well I doubt there is anything you can do...perhaps it just freezes occasionally and at random of its own accord. Remember, the keyboard itself becomes unresponsive until restarted. That is odd, although it could still be the result of something happening at its USB interface. Recall that error which happens at the same time, but does not show in the RG logs, but in the kernel logs:

kernel: sound midiC0D0: rawmidi drain error (avail = 4022, buffer_size = 4096)

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?

If (2), I'm using debian bookworm 6.1.0-40 whereas trixie is at 6.12.48. I am still testing trixie and will soon upgrade

Your mentioning of the .rg file being loaded twice is interesting because the scenario where this was first noticed, involves the following sequence of events:

1. Command line open of RG into a session
2. Use wmctrl to close RG
3. Command line open of RG into a second session
4. etc

And that sequence is scripted for the sessions I want to work through without filemanger hunting.

Each time RG is restarted, even though via command line, I suspect the default studio is still opened in between? I don't actually see it...only the final session on the command line. Hence, possibly the two rg files you mentioned? And as a script, timing might be involved. The only problem is that I can go through a dozen sessions like that for a month and only get stuck once. So, it just doesn't pan out as a cause.

Well, there are the two questions above, and I suggest leaving this bug open until I upgrade. The OS error messages may well be clearer if the problem still occurs and right now it's rare enough to get by with and no one else has reported a freeze.

[musewhirl]

There are surprisingly few references to drain error. And it's not certain whether this occurs just prior to, after or even at the same time as the bug report. But it is certainly always shows up in the kernel logs at about that time.

I found this link which itself contains familiar language i.e. "stopped responding" and "taking down the stack":

https://github.com/hathach/tinyusb/issues/735

In it there is another link to a related issue mentioning issues when not dealing with sent/received MIDI data correctly:

https://github.com/hathach/tinyusb/pull/618

In that last link, they also mention MIDI, USBs, SysEx and blocking. Their short discussion may provide you with some clues, assuming the problem has anything to do with RG.

Anyway, it's just info. Waiting for the upgrade to trixie will provide useful information.

[musewhirl]

I found something odd when RG is opened via the command line rg file argument. As mentioned previously, to avoid JACK errors when kill is sent to RG in a script, I use wmctrl to close it instead before another command line start:

wmctrl -c "- rosegarden"

After that, I was temporarily using a sleep of 1 sec to allow RG to close down, but never returned to update my script. That was a mistake...it can take longer...occasionally...even though it is not on the screen. So, I went back to favoring state to determine if RG is actually closed. It's still not perfect, but I use the ps command in a while loop to check, along with a short sleep. And I was surprised to see how often it took time closing, more importantly along with the following difference in the RG logs.

Normally, when RG is started, the default studio ends with the lines above the dots in the following log. And when another session is opened via the Recent list, the observers WARNING appears (harmless).

[StartupTester] StartupTester::StartupTester(): URL:  "http://www.rosegardenmusic.com/latest-version.txt"
[StartupTester] StartupTester::slotNetworkFinished(): Connection failed:  "Host www.rosegardenmusic.com not found"
...
[Composition] dtor: WARNING: 3 observers still extant:

On the other hand, when the wmctrl command is used in a script, followed the sleep loop before starting another command line, RG has an extra, unexpected line. I appended my own logging during the sleep loop:

[StartupTester] StartupTester::StartupTester(): URL:  "http://www.rosegardenmusic.com/latest-version.txt"
[StartupTester] StartupTester::slotNetworkFinished(): Connection failed:  "Host www.rosegardenmusic.com not found"

waiting for RG to close [1]...
[SequencerThread] run(): Sequencer status changed from  0  to  7
waiting for RG to close [2]...

[Composition] dtor: WARNING: 3 observers still extant:

I usually only see that status change with select play, where it goes from 0 to 1, and when I stop RG and it changes from 1 back to 0. Naturally, I assumed it was a boolean.

The obvious question is what is the meaning of a status of 7? Why would that show up presumably while shutting down?

It's probably nothing, since this thread is full of red herrings, but I might as well ask, since timing often leads to apparent random issues which are difficult to reproduce.

[Ted Felix]

7 is quit.

typedef enum
{
     STOPPED,
     PLAYING,
     RECORDING,
     STOPPING,
     STARTING_TO_PLAY,
     STARTING_TO_RECORD,
     // SequenceManager uses this state when we go to record.  We stay
     // in this state until recording begins.  Usually recording begins
     // immediately, but in the past, the CountdownDialog would delay
     // the actual start of recording.
     RECORDING_ARMED,
     QUIT
} TransportStatus;

[musewhirl]

Well, the issue occurred with trixie too. Assuming that enough of the OS, including ALSA has been updated since bookworm, then the problem survived the upgrade. That still leaves RG, and of course the keyboard, and possibly JACK since it owns the keyboard USB interface.

But there was an important change of behavior relevant to this thread. RG always froze for 10-15 secs (probably just under 10s in reality). But now it was more of a hiccup lasting a split second. If I had not been sensitized to the current issue, I would not have noticed. Just the thought crossed my mind and instead of hitting play in RG, I reached for the keyboard buttons...frozen. And then no sound from RG on play.

Also important is that the midi drain error was not in the journal when the non-sounding RG was open. I always figured that the problem must occur while the previous RG is closing or while the next launch was in progress. Because neither RG nor JACK have timestamp logs, it was never clear when that drain error appeared, but it was always there.

Then I made a mistake. I remembered to close RG first and the drain error was not in the journal...and I intended to wait much longer (full 2 mins) to be sure it hadn't just been delayed. I instead turned off the keyboard, even forgetting JACK was still up. When I checked the journal, the drain error was there along with the usual kernel complaints about xhci_hcd. In any case I have to wait all over again.

Conclusion: RG always froze for a lengthy time, so if that does not occur next time then this bug, by description, no longer occurs in trixie. Furthermore, I built using the same master zip used in bookworm, except now it's qt6 and gtk3. That would mean that something outside of RG must have changed.

Let's wait for the final curtain call though.