#1225 Non-plugin synthesisers do not play when Rosegarden uses RTC
To achieve the proper MIDI timing I had to use Rosegarden with the snd-rtctimer in my Debian/testing GNU/Linux system (I couldn't use the snd-hrtimer, as it immediately freezes the system until hardware reset).
However as soon as I select snd-rtctimer as "Sequencer timing source" all external software synthesizers (connected via qjackctl "Connections" manager ALSA tab) stop playing.
The notes played on external MIDI keyboard are routed and played correctly.
In the "pianola editor" all notes played on the virtual keyboard are played correctly.
The notes stored in the track are not played at all even though the Rosegarden seems to play them (the indicator replacing the track number in the main window blinks, showing the volume of the tones played).
As soon as I select the system timer as the "Sequencer timing source", external synthesizers start to work correctly - without any other changes to the configuration.
I've tested this behaviour with ZynAddSubFX and with FluidSynth (via qsynth) - both behave the same way.
The plugin synthesisers are not affected by this problem.
Output of amidi -d -p hw:3,0 for RG with System timer
Output of amidi -d -p hw:3,0 for RG with RTC timer
I have verified, that the problem is associated with the Rosegarden (or with JACK?) and not with synthesizers.
I have connected the Virtual MIDI device in parallel to the QSynth to the same output of Rosegarden.
I have recorded the MIDI messages send to this output with "amidi -d -p hw:3,0 > file".
I can see, that the notes are correctly sent and played, when "system timer" is used (see norm.dump.gz), while no notes are sent, neither played, when "RTC timer" is used (see rtc.dump.gz).
I have also dumped the sequencer status from the Rosegarden (I have switched the sequencer timer between "system timer", "RTC timer" and "PCM capture 0-2-1").
Rosegarden 1.7.3 - AlsaDriver [ALSA library version 1.0.19, module version 1.0.20, kernel version 2.6.31.6.media]
JackDriver::initialiseAudio - JACK sample rate = 48000Hz, buffer size = 1024
JackDriver::initialiseAudio - creating disk thread
JackDriver::initialiseAudio - found 12 JACK physical outputs
JackDriver::initialiseAudio - connecting from "rosegarden:master out L" to "system:playback_1"
JackDriver::initialiseAudio - connecting from "rosegarden:master out R" to "system:playback_2"
JackDriver::initialiseAudio - found 8 JACK physical inputs
JackDriver::initialiseAudio - connecting from "system:capture_1" to "rosegarden:record in 1 L"
JackDriver::initialiseAudio - connecting from "system:capture_2" to "rosegarden:record in 1 R"
JackDriver::initialiseAudio - initialised JACK audio subsystem
ALSA Client information:
Creating device 0 in Play mode for connection 130:0 Synth input port (10792:0) (write)
Default device name for this device is MIDI software device
Creating device 1 in Play mode for connection 20:0 E-MU Xboard49 MIDI 1 (duplex)
Default device name for this device is MIDI external device
Creating device 2 in Record mode for connection 20:0 E-MU Xboard49 MIDI 1 (duplex)
Default device name for this device is MIDI hardware input device
Creating device 3 in Play mode for connection 28:0 VirMIDI 3-0 (duplex)
Default device name for this device is MIDI software device 2
Creating device 4 in Record mode for connection 28:0 VirMIDI 3-0 (duplex)
Default device name for this device is MIDI software input
Creating device 5 in Play mode for connection 29:0 VirMIDI 3-1 (duplex)
Default device name for this device is MIDI software device 3
Creating device 6 in Record mode for connection 29:0 VirMIDI 3-1 (duplex)
Default device name for this device is MIDI software input 2
Creating device 7 in Play mode for connection 30:0 VirMIDI 3-2 (duplex)
Default device name for this device is MIDI software device 4
Creating device 8 in Record mode for connection 30:0 VirMIDI 3-2 (duplex)
Default device name for this device is MIDI software input 3
Creating device 9 in Play mode for connection 31:0 VirMIDI 3-3 (duplex)
Default device name for this device is MIDI software device 5
Creating device 10 in Record mode for connection 31:0 VirMIDI 3-3 (duplex)
Default device name for this device is MIDI software input 4
Creating device 11 in Play mode for connection 14:0 Midi Through Port-0 (duplex) (not connecting)
Default device name for this device is MIDI output system device
Creating device 12 in Record mode for connection 14:0 Midi Through Port-0 (duplex) (not connecting)
Default device name for this device is MIDI input system device
Current timer set to "RTC timer" with timer checks
AlsaDriver::initialiseMidi - initialised MIDI subsystem
ALSA Client information:
AlsaDriver::setPlausibleConnection: connection like 16:0 Hammerfall DSP: MIDI 1 (duplex) requested for device 0
AlsaDriver::setPlausibleConnection: fuzzy match 14:0 Midi Through Port-0 (duplex) available with fitness 3
ALSA Client information:
ALSA Client information:
ALSA Client information:
ALSA Client information:
ALSA Client information:
It seems, that the problem which I have reported is rather old.
It looks very similar to http://sourceforge.net/tracker/index.php?func=detail&aid=1757981&group_id=4932&atid=104932
which seems to be never fixed.
Sorry I haven't responded to any of this yet, Wojciech. I have no idea what to say, to be truthful. I don't have the snd-rtctimer module available, so I can't confirm this finding at this time. If I did confirm it, I would not be able to do anything with that knowledge. I don't know anything about these issues, and would not likely be able to fix anything.
I do everything I can, but these issues are beyond my reach to do anything about.
Debug log from the operation with the system timer (playing of short melody)
Debug log from a run, where I have only switched the timer (between SYS and RTC)
Debug log from the operation with the RTC timer (playing of short melody)
Michael, thank you for your comment. Well, I'll try to investigate the problem myself, or maybe someone else will be able to do it.
I've attached logs obtained from the RG compiled with debugging on
(I've modified the CMakeLists.txt file:
SET(CMAKE_CXX_FLAGS_RELEASE "-O2 -w -fexceptions -DNDEBUG")
SET(CMAKE_CXX_FLAGS_RELEASE "-O2 -g -Wall -fexceptions -DDEBUG")
SET(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -g -Wall -fexceptions -DDEBUG")
SET(CMAKE_CXX_FLAGS_DEBUG "-O0 -g3 -Wall -fexceptions -DDEBUG")
and recompiled. Later I have switched on debugging of all Rosegarden related info to the kdebug.dbg file
using the kdebugdialog )
I hope that the attached logs may be useful for someone with better knowledge of the RG internals.
In fact the problem seems to be rather important.
For me (and probably not only for me) RTC is the best timer source.
Setting of system timer to 1000Hz is a kind of overkill (in fact I use the tickless kernel with HZ set to 300).
For me its even worse - my DAW system just doesn't boot with kernel compiled with HZ=1000 (exactly: panics trying to mount the rootfs from the SATA drive, claiming, that this disk does not exist) .
May be it is associated with the fact that this is a SMP machine.
Well, the HR timer could be even better than the RTC, as it allows to precisely schedule interrupts with very high resolution without need to trigger them periodically, so we can have both: high resolution and low interrupt related system load at the same time! Unfortunately AFAIK RG works unreliably with HR timer for many people...
In my system selection of the HR timer freezes the system immediately.
Probably this is not RG related problem - if userspace application is able to freeze the system, it rather means, that there is something wrong on the kernel/driver level...
Second set of logs - kdebug_rtc.dbg - playing with RTC, kdebug_switch.dbg - zwitching from RTC to SYS, kdebug_sys.dbg - playing with SYS timer
The first set of logs is very interesting (please note multiple "Rosegarden (notation): NotationGroup::NotationGroup: Rejecting sample()" messages in the log from playing with RTC), but it seems, that another effect has been added to the main problem.
I have repeated my experiment, and now both logs - for playing with RTC and with SYS timer are more similar.
Results are in attached debug_logs2.zip file.
Since you really have your teeth in this problem, I feel I should point out that it may be worth playing with the beta of 10.02 codename "Thorn" I'm going to release in the next few days. If it's worth really digging into some sequencer timing problem, it's probably worth looking at it from a current perspective.
I doubt we'll be lucky enough that the problem has gone away in Thorn. If anything, I'm expecting it will probably turn out to be more difficult to debug now that the sequencer runs in a thread instead of a separate application. Hopefully not, but we might as well see how something like this is going to go. There's no going back to the abandoned KDE code from here.
OK. So now I can only confirm, that the same problem exists in the rosegarden-10.02-alpha2, which I have compiled today,
The external soft synths do not play with RTC timer, and do play with system timer.
Even though I was not able to fix the problems with the RTC timer, I had a very fruitfull discussion with the author of the snd-hrtimer, and now I'm able to use the HR timer instead of RTC timer in my system.
I hope, that the version of the snd-hrtimer working reliably will be available soon.
We had a Gentoo user who had to recompile his kernel to fix a similar kind of issue. Rosegarden thought it was playing normally, but nothing was really happening. The RTC timer was implicated, or at least some kernel compile option pertaining thereto.
I have no idea what's going on with any of these timing issues, I'm simply mentioning a data point.
More of a "can't fix" than a live with it, but the result is the same.