I think that shortening the piece may cause it to not encounter the problem, as my short recordings (where I made a mistake, and stopped recording early) haven't failed yet. 

One thing that might be helpful, is that I think that qsynth is not a necessary part of reproducing the problem.  I'm pretty sure I have reproduced it using the emu10k1 synthesizers in the Soundblaster Live card. 

In fact, just this afternoon I tried it on a 933 megahertz machine, running Lubuntu 12.04, using the Soundblaster Live! emu10k1 synthesizers, and duplicated the problem.  I use Lubuntu rather than Ubuntu because there is noticeably less overhead - it runs visibly faster. 

I'm not sure what you describe about "for MIDI recording because it sucks up too much CPU".  But it sounds like what I describe in the following paragraphs.  Please forgive me if I have embarked on giving you information that is not useful. 

With the way qsynth is installed, it doesn't do the configuration change you need to prioritize the interrupts.  I wish it would do that change for you when you install, but it doesn't (and it didn't need to do so before Ubuntu 11.10). 

It used to be that you didn't have to worry about that - it would just work.  But with the last two Ubuntu releases (11.10, and 12.04), it appears that changes to the kernel have introduced so much overhead, that it is now necessary to configure real-time priority and memory-lock limits for yourself, in order for qsynth to work without 'cutting out' (getting under-runs). 

With this configuration change, even a 450 megahertz machine (using Lubuntu 12.04) will run qsynth, playing my quite complex demo-music '.rg' files without under-runs, so a little configuration change can go a long way! 

In the directory "/etc/security/limits.d", create a file with the following contents (except everywhere "aere" appears, substitute your user-ID:

aere - rtprio 85
aere - memlock unlimited

After the user-ID in the above file, is a " - " (space hyphen space) character-sequence.  The filename must be in the form "aere.conf", where (again) you substitute your user-ID for "aere". 

There is probably already a file "audio.conf" in that directory, but making yourself a member of the audio group will not solve the problem (at least, it didn't solve it back when I was originally chasing this problem). 

So if your user-ID were "ted", you would create a file whose name is "ted.conf" in the "/etc/security/limits.d" folder, containing the following lines:

ted - rtprio 85
ted - memlock unlimited

After you have done that, you need to reboot, because this information is only looked-at during the system-load processing. 

After doing that, qsynth should work without problems. 

My automated installation process for my MIDI training courseware actually makes that configuration change for the user, and another change allowing large soundfonts to be loaded into the emu10k1 (soundblaster) synthesizers. 

Without the configuration change described in prior paragraphs, I get frequent under-run errors, even using my 2.5 gigahertz machine.  Before Ubuntu 11.10, I would never (or seldom) get under-run errors, on all but my slowest machines.  Now, it is absolutely necessary on everything but very fast machines. 

I hope I have guessed right what your problem was.  If so, this should really help you in using qsynth.  For slower machines, you may also need to limit the polyphony parameter in qsynth to 64, but then you may also need the fix to libfluidsynth1 that the fluidsynth developers neglected to make available for Ubuntu 12.04. 

- Aere

On Sat, 2012-06-23 at 18:31 -0400, Ted Felix wrote:
On 6/23/2012 1:37 PM, Aere Greenway wrote:
> I installed Rosegarden 12.12 there without any problems -
> congratulations on your straight-forward, accurate, and detailed
> instructions.

   Wow.  I hadn't actually tried my exact instructions because I have a 
script that installs all the rosegarden dependencies for me.  Glad to 
hear it works.

> Knowing this problem does not always occur, I decided to try it again.
> This time, at the end of the recording (when I clicked the "Stop"
> button), the Rosegarden window was unresponsive, suggesting a hang.
> In my terminal window, I saw it had indeed crashed.

   Ugh.  Ah well.  Can you shorten the test case by just recording the 
last 4 bars of your piece?  It might not work, but if we're lucky it 
will, and I can more easily reproduce it.  I haven't been using rg at 
all for MIDI recording because it sucks up too much CPU and I've been 
trying to fix that.  Maybe I should just try recording material similar 
to what you are working with.  I might be able to stumble on this too.

   From the looks of your output this appears to be a new problem.  
However, there isn't really very much to go on.  Not sure if the core 
dump will be worth anything.  If you could fire up gdb and get a 
backtrace from the core dump, that might be helpful.

$ gdb rosegarden core

   That should get you in.  Then type bt and hit enter for the 
backtrace.  (I think.)


Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe