#1687 RG will not start session with previously saved MIDI interface
RG will not start a session with the correct MIDI interface, even if saved with it previously. Finding the steps to reproduce this was extremely difficult, and I am not surprised this was not seen before:
- This only happens with a keyboard which has an audio interface with more than one port e.g. 20:MIDI-A and 20:MIDI-B
- Also, the user has to not only create a new MIDI playback device,
- And in addition delete the default one which came with RG
I carried out the steps using [d0760d], although I will be moving to a later version shortly. I'm sure it's still in whatever sourceforge master is out there.
Steps to reproduce:
- Start fresh install
- Open Manage MIDI Devices
- For the default session, RG chose the same port, e.g. 20:MIDI-A, for both output and input
- Click New to create a playback Device
- Click Banks... and Import e.g. GM2 from the RG library
- Select 20:MIDI-A for that bank
- Set the default "General MIDI Device" to "No port"
- In RG's main window delete all MIDI tracks (they are using General MIDI Device)
- Now in Manage MIDI Devices you can delete the General MIDI playback device
- Then add back some tracks just to show that they will be using the new GM2 playback device
- Save session as: session-A
- Close session and, only because I did in these steps, restart RG
- Open session-A
- Open Manage MIDI Devices
- Session-A is set to 20:MIDI-B NOT 20:MIDI-A as when saved above
I was mystified for some time. But my guess is the following, after looking at session rg files which worked and ones that didn't. For a fresh install, there are only two devices of consequence i.e.
- The default General MIDI Device (id=0)
- The "MIDI input system device" (id=1)
...both port connections are the same
I think that order may prove significant. When a new playback device is added, it gets id=2. And if the user no longer needs the default "General MIDI Device" e.g. new device contains GM and more anyway, they delete it. So the rg file now has:
- MIDI input system device is id=0
- The newly added playback device is id=1
...and of course both connections are still the same.
For some reason, when started this way, RG will no longer have the correct MIDI output port, it chooses a different one IF one is available. For a single MIDI port, there is no alternative, so I guess it does nothing (or errors) and uses it anyway, and no one is the wiser.
The basis of this bug is that RG selects a port overriding what was saved, and that port might not be a port the user wants or can use for this purpose. All supposition, but first it needs to be reproduced.
Then let me know what really is going on. BTW: I have whole heap of sessions that fall in this category.
I can reproduce this.
It seems the stored port is being ignored because it is in use (as an input device).
Why are in use ports skipped ? Seems strange to me.
Another consequence:
create a second midi device and connect to the same port as the default device (surely not an unusual use case).
Check the midi device dialog - both devices use the same port.
Save this and load it again. One of the devices has lost the port connection !!
Should we remove the
portInUsecheck inAlsaDriver::setPlausibleConnectionThoughts anyone ?
I can't suggest anything yet because not enough information is available. But first I'll make sure you noticed the following which is also going on.
Check the contents of the rg file itself at each point a Device is added, port changed and saved. I saw device ids and the name attribute of devices come and go, but the connection attribute is not updated in the file, even though the Manage MIDI Devices window ports are different. I still have connections from an old audio interface that I don't even use anymore...but everything worked regardless. That bothered me too, but it seemed like RG was using the ones shown to the user i.e. the ones it discovered. I need to be sure that configuration issue is not a cause of the skip.
I normally leave RG to manage the rg files, since a typo or misunderstanding could leave to unknown issues. However, as an independent test, which I did not mention, I actually changed the connection in the rg file to match the real world...replaced that old interface name with the one in use...and alas that literally caused the skip on the next RG launch. That was when I made a note to create the bug.
Also look into another possibility for the skip i.e. could it be that the name of the connection was not taken into account when checking for ports in use? Without that then to the code this could look like a problem:
leading it to try a different port instead:
While the following would have been OK:
Just a guess though.
AlsaDriver::setPlausibleConnection()does some audit logging to help diagnose these sorts of issues. Can you run the problematic test case and post the audit log? You can find the audit log in Edit > Preferences... > Details... button in the lower right.This should help clarify things for me since I don't have appropriate test hardware.
Here is the relevant part of the audit log for my test case above - two playback devices using the same port:
Note the "nothing suitable available" lines although an exact match for the port is available.
The correct port seems to be rejected because it is already in use (from the first connection).
I believe the
portInUsecheck is wrong.Thanks, Philip. I'll take this case into consideration.
@musewhirl, can you post your audit log output from when this is failing for you?
I don't know anything about the portInUse function, but see the essentials of the audit logs below. NB:
RG fresh install start up
This is where RG starts, generates its own autoload and discovers MIDI ports. Since there is no rg file as such, the conditions mentioned above do not occur. The client information is repeated throughout the logging, so I present only the first appearance here:
"Manage MIDI Devices window" matches in this case i.e. both play and record get 16:0:
Loading a problem rg session file
First the original setup:
NB: A failure to subscribe occurs here for the record port on device 0:
But:"Manage MIDI Devices" window indicates that record port for device 0 is 16:0 even though the audit log appears to say it failed?
Swap order of devices in the rg file
All I did next was change the order of the devices in the file i.e. play before record:
The words failed to subscribe no longer appear like it did above. In fact, it even says "successfully subscribed" (or something is):
The "Manage MIDI Devices" window indicates that play port as device 1 now gets 16:0 while the record port ends up displaced with 16:1.
It's still wrong, but no sign of failure in the log.
Thanks for the super-detailed info. Now it's a lot clearer to me what's going on.
I need to dig some more, but I suspect the issue is that rg doesn't properly support duplex ALSA MIDI ports. I don't think I've ever seen that on my test system. I might not have the right type of hardware or this might be a newer version of ALSA collapsing pairs of in and out ports into duplex ports. If this is a new ALSA feature we'll need to be careful to support old and new ALSA.
You mentioned that you might not have the right hardware to see this problem. With my previous keyboard, I didn't see this problem either. My guess is because that keyboard only had one MIDI port e.g. 20:0. The only other port showing up in the "Manage MIDI Devices" was 14:0 Midi Through Port and RG never picked that. A newer keyboard started showing this issue. It had ports e.g. 20:0, 20:1 etc and I thought that this problem started because RG had an issue with the subports of port 20.
However, after your post, I was curious to see if I could eliminate the hardware side of this. It may not help in your case, but it's worth mentioning as a place to "dig some more". It involves using virtual MIDI ports. It took a number of internet sources before I had something I could try...I should mention the main ones just as a reference, but after that I will describe what I did to get our particular problem. And I apologize in advance if this is all just "old news" to you.
First clue was the linux kernel module: snd-virmidi (mentioned here and that's all I got from that link):
https://tldp.org/HOWTO/MIDI-HOWTO-10.htmlAnother piece of the puzzle which added a bit more control was the midi_devs parameter for the module mentioned here:
https://unix.stackexchange.com/questions/498222/how-create-a-second-midi-deviceIn the end I tracked the source code to the following link because I still could not get what I wanted:
https://codebrowser.dev/linux/linux/sound/drivers/virmidi.c.htmlBut I got something...the error without involving hardware.
I unplugged the USB to my external keyboard to get the following:
Fancy way of saying "no ports available" :-) NB: This will probably still work if just one existing MIDI port was around, because now there will be multiple allowing the problem to occur.
Steps to reproduce:
Load snd-virmidi, where the '1' is the index of your next available sound card (as per the first link) and I've added just '2' ports (without the midi_devs the default is 4 as per the source code):
modprobe snd-virmidi snd_index=1 midi_devs=2Now we get:
Start a fresh install RG, and sure enough, RG sees and uses them, but note that I didn't get the subport numbering I wanted i.e. 20:0 and 20:1:
Save the session as test.rg, and open that session again:
The selection for the inputs has changed! A fresh install and no messing around renaming connections in the rg file itself.
Since these are virtual ports, and you can create even more than just two, you may be able to dig into what's going on using alsa utils like aconnect to redirect those ports etc which might help with resolving the issue, if you haven't already.
I did not have the hardware to test this directly. I wrote a small test program which creates 2 duplex ports. See attached - it may be helpful
compile with:
g++ apt.cpp -o apt -lasoundJust pushed a fix for this to master as [663099]. Please test latest git.
I agree with Philip. The problem is
portInUse(). I've removed it and things seem better. I do have a keyboard that appears as duplex, so I was able to test this all along.Grand scheme of things, checking for ports in use is more of a "just connect something" approach which doesn't make sense when an .rg file is being loaded onto the same setup where it was created.
Let me know how testing goes.
Related
Commit: [663099]
The bug, as reported, is fixed. When the play and record devices have the same connection name, there is no conflict or change to use another port.
But I did notice something which would not have been observed if I had not been involved in analyzing the bug. The autoload.rg for a fresh install starts out with no connection name for either device which is fine:
However, I think I mentioned somewhere along the line that previous sessions still contain the record device's connection name of an old keyboard. Being different from the playback device, there was never a port conflict...just an inconsistency if one looked in the rg-file...in fact synchronizing that name is the step which started this bug. I tried one of those old sessions with the new code:
So, I can manually fix all of my old sessions, if I choose to. As far as I can tell, RG probably ignores the connection name of the record device in the rg-file itself in favor of the one it finds in the actual MIDI device (untested assumption).
The only remaining inconsistency would be why did a new session save with both names updated, while the old session did not? Perhaps because the connection name was empty for the new session? But that begs the question of whether both connection names should always be saved to the rg file with what the user saw in the MIDI Manage Devices window prior to hitting save.
So rg is not saving the record device connection? Is this happening only when it has to find a new one? Or is it also happening if you manually change the record device connection?
It might be designed to preserve the incorrect one unless manually changed. This might make sense if you load an .rg file and forgot to connect your main controller keyboard.
Correct.
Can you rephrase that question?
The old sessions rg files were never manually changed, but were created using previous versions of RG. Those version and those sessions were in use when I changed keyboards. In those cases, I recognize the old record connection name as an old keyboard, but that can't matter to RG...it's likely that any name in the record connection will not be updated. But since a new session created with both old or new code does get saved with the record name, then RG must be putting it there prior to saving the session for the first time. It's likely it won't update that in the future either based on the evidence so far.
Well, in that case, the Manage MIDI Devices window usually has no port selected for either playback or record and as a result, I would not expect it to interfere with the current connection names in the rg file anyway. However, when the record connection is not saved, the Devices window appears to show the user what is going to be saved...but only saves it partially i.e. the playback.
If you think that RG is designed to never update the record connections, and it won't affect MIDI recording by new recording devices (untested of late), then this would not be a bug but a feature and hence could be closed, since rarely will anyone actually look inside an rg file to notice?
Procedure:
For this procedure, between step 9 and 10 above, manually force the record device via the device manager to keyboard #2. You might need to assign it to something else (e.g. that Midi Through Port that is always there) and then back to keyboard #2.
I'm guessing procedure #1 results in keyboard #1 being preserved since rg wasn't told to do anything specific with it. And procedure #2 will change what is saved to the .rg file to keyboard #2 since it was asked to do that.
This is sort of a "don't mess with what we don't understand" mentality that is typical of XML files.
Whether any of this is the right thing to do is an entirely different question. We've not had a lot of complaints related to record devices. Mostly playback.
Your guess was spot on.
I had originally misinterpreted "manually" to be changing with the rg- file again. But what you meant was for the user to use the GUI to tell RG that a change in port is desired. When you do that, RG's "saved required" indicator comes on and after saving the supposedly misbehaving record connection name was updated correctly. And we know its preserved otherwise because that behavior was previously reported.
As for fixing the past stale data, as far as I can tell RG always works with what it shows in the Manage MIDI Manager anyway, so users do not necessarily have to bother (and most won't even know). I now have the simple option you provided when I return to an old session or there is always a sed script to automate purging the old name en masse.
That covers all angles of the bug. It's tested and determined as a fixed. It was the automatic swapping of the ports which was the main usability problem.
Great fix!