(OpenSUSE 12.3 patched up to date)
I’m using Rosegarden with QSynth to play midi under Pulseadio and it works fine and consistently.
The USB connection between my M-Audio Prokeys 88 and the computer is very unreliable.
Occasionally I can randomly get it to work, but then if I change something it probably won’t work again.
I’m trying to troubleshoot the issue, and any hints you can give would be helpful.
This is what I see:
In Rosegarden, the Studio - Manage Midi devices sees “USB Prokeys 88” on the in and out no problem.
Out is set to Qsynth, and in is set to prokeys.
If I load a MIDI file in rosegarden and play it through the output I get output as expected.
MIDI thru is enabled in Rosegarden, but when I press keys on the Prokeys I get silence from the computer output.
(It works sometimes, about once in 20 tries or so, it appears random)
So, I think the first thing to check is that the keyboard is sending control output and
the computer is getting it. I installed a command line set of progs portmidi and tried
portmidi-midithru and I don’t see any output from the keyboard registered at the computer.
The keyboard works fine connected to a Windows machine running Sekaiju. So it is sending CCs.
Sometimes if I start my linux setup fresh in the correct order Qsynth, Rosegarden etc
and then very quickly start playing at the Prokeys it will play correctly through speakers and then suddenly stop.
Playing period (if it works at all) is about 10-30 seconds before it shuts off.
Qsynth has a MIDI message reporting ability with a check option in the setup,
it then reports all incoming CCs to the message window.
So I’m thinking this is a timing issue. Somewhere along the line the interleaving of commands
loses its way. Probably another situation where Pulse is not quite as good as Jack, and will have to wait for
my next new box so that I can replace pulse on this one with Jack and try again.
Yes, thanks, I found that reference too, did that,
but no difference apart from the fact that the messages from Qsynth about not being able to set the timing stopped.
Ok, sorry I diidn’t realize that we had exchanged experiences about rosegarden/qsynth/pulseaudio in that other thread back around mid March.
I revisited it to see when I last had it working, as I had a problem just playing midi files today. I had forgotten about the prob with Rosegarden starting jackd (not required by us). I had noticed that Qsynth has been updated about seven times by Packman since the beginning of March! That may not have helped your testing.
Anyway just now, I accidentally started rosegarden before qsynth for another try, and noticed jackd start and disappear on closing rosegarden but don’t recall that happening before(?). So I started qsynth followed by rosegarden this time, looked for jackd’s process to kill it, but it hadn’t started, oh good and midi files play ok! I will try that again later to see if it’s reproducible as a way to avoid the usual hit 'n miss killing fiaso.
I connected my Zoom effects processor via usb, to see what 12.2 with KDE + rosegarden/qsynth/pulseaudio made of it if anything. A very long time and several openSUSE releases since I had it connected and working as an audio interface (not midi), and that was with Jack. So far KDE/Phonon detected the device and KMix has it as a playback and capture device. However I think rosegarden will need Jack (IIRC configured for duplex operation) to handle the audio side.
Is your midi device powered via usb or separately via mains/battery?
If we consider the output side to be completely independent of the input setup then Rosegarden works fine under PA. I have it working regularly and reliably to play MIDI files as long as jackd is not loaded. On Opensuse the output sound quality is way higher than on the Windows machine with GM synth sounds and it is much easier to manage the various soundfonts on linux.
The Prokeys 88 is a full standalone stage piano which is independently powered.
So my workaround so far is to record MIDI input via windows using the monitor output from the keyboard to create the MIDI file and transfer it to linux for edit and final output.
Just wanted to add that this had a very beneficial effect on screen recordings with xvidcap.
Without these commands in place I would get about a 1 sec. offset between audio and video.
With these commands in place the sync of audio and video was much more acceptable.
I assume your device is listed correctly (as seen by command “lsusb”).
Have you tried connecting your keyboard (midi controller) directly to qsynth/fluidsynth using alsa’s midi connection facilities? That should be handled simply by pulseaudio’s alsa plugin. At least you should hear something. Your midi controller should show up using “aconnect” -i (should show alsa’s readable midi ports). Using “aconnect -o” in user terminal gives me writable port for qsynth:
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 128: 'FLUID Synth (3964)' [type=user]
0 'Synth input port (3964:0)'
Just type “aconnect” without parameters to get Usage re connect/disconnect, then make the connection, use the keyboard and hopefully get audio output from qsynth via pulseaudio and speakers, as a low level test.
Excellent suggestion, one which revealed the problem.
lsusb has always seen the keyboard no problem. However it seems that is not the whole story.
The keyboard can be in a state of being “seen” by the system but unable to send commands reliably.
The bad link in the chain was that I was using an external usb extension hub. An extremely short one which is fine for things like bluetooth adapters, and overall length of cable is way shorter than the max of 4 meters or so.
However…
I should have taken seriously the fact that when I plugged the keyboard into the usb extension, the bluetooth adapter light would go out.
So I bypassed the extender, plugged the keyboard directly into the CPU box and applied your suggestion.
The aconnect thing worked. This time I could play directly to Qsynth from the keyboard.
I loaded Rosegarden and found it would record while playing through speakers.
Problem solved.
Last thing to check was whether the system would need the aconnect command each time, so I rebooted, started Qsynth and then Rosegarden, and the keyboard started playing immediately.
As far as I can tell it is Rosegarden that takes care of the aconnect instruction, and as long as that darned USB connector is not in the way it does so effectively.
