Ted:
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.)
>
> Ted.
>
> ------------------------------------------------------------------------------
> 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@... - use the link below to unsubscribe
> https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
--
Sincerely,
Aere
|
