From: Geoff K. <gs...@gm...> - 2010-02-26 03:41:53
|
On rosegarden 10.02.... How much CPU should rosegarden be using? I've got 5 tracks with some midi stuff that I recorded. It is sent to 3 different external keyboards. Nothing else going on at all. It is eating up ~50% CPU. It seemed high to me, but I wanted ask here first. This is on a 3 year old dual core desktop running ubuntu lucid, usually plenty fast for my purposes. Let me know if you'd like a more thorough report or have questions. Thanks. Geoff |
From: D. M. M. <ros...@gm...> - 2013-08-26 12:43:44
|
I'm using Rosegarden to do something for the first time in a very long while. I said, "Damn!" out loud once I noticed the ridiculously low CPU usage. It was running like 5-6% instead of 80-90%. That's a HUGE improvement I never really appreciated until just now. FWIW, Ted. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2013-08-26 16:38:09
|
> I'm using Rosegarden to do something for the first time in a very long > while. > > I said, "Damn!" out loud once I noticed the ridiculously low CPU usage. > It was running like 5-6% instead of 80-90%. That's a HUGE improvement > I never really appreciated until just now. > > FWIW, Ted. Yes. Good work, Ted! Tom Breton (Tehom) |
From: Ted F. <te...@te...> - 2013-08-26 20:22:31
|
On 08/26/2013 12:38 PM, Tom Breton (Tehom) wrote: >> It was running like 5-6% instead of 80-90%. That's a HUGE improvement >> I never really appreciated until just now. >> >> FWIW, Ted. > Yes. Good work, Ted! Thanks guys. There should be more to come. Nothing quite as dramatic, but certainly enough to be worth the effort. Ted. |
From: Chris C. <ca...@al...> - 2010-02-26 20:19:06
|
On Fri, Feb 26, 2010 at 3:41 AM, Geoff King <gs...@gm...> wrote: > On rosegarden 10.02.... How much CPU should rosegarden be using? I've > got 5 tracks with some midi stuff that I recorded. It is sent to 3 > different external keyboards. Nothing else going on at all. It is > eating up ~50% CPU. That does sound high. CPU usage at the moment is a bit on the high side, but much of the problem is that it seems to depend a lot on the environment -- it appears that it can be fine on some (even quite low spec) hardware but relatively rather worse on other hardware with different video drivers, etc. In that respect it's significantly less predictable (and therefore worse) than 1.7.x. There is some way to go on improving this stuff, particularly with regard to how refreshes are handled. Try adjusting the "graphics mode" setting in the first page of the configuration dialog; if that doesn't make any difference, try (experimentally -- not really recommended for normal use) switching off the "use Thorn mode" toggle in the presentation tab. If either of these makes a significant difference, it would be interesting to know about it. Note that both require the application to be restarted after any change. Chris |
From: Geoff K. <gs...@gm...> - 2010-02-27 14:45:44
|
Hi Chris, Playing around with it as you suggested, I haven't found any solution. Here's some findings that might be of interest... -"graphics performance" - about the same -"thorn style" - about the same -different video driver opensource "nv" and "intel" (motherboard video) instead of proprietary "nvidia" - CPU is about the same on all. -tried both ubuntu karmic with realtime kernel and ubuntu lucid kernel+1000HZ and both are about the same on the same computer as dual boot. -tried ubuntu's rosergarden packages for lucid and current SVN = same -tried with both jackd on and off = same -tried moving midisport patchbay to other USB bus (was on same as video) = same Looking at "top" while playing shows. ./rosegaren at cpu of ~50% and /usr/bin/X at ~30%. one on each core. It's slightly dependent on number of tracks, but even with one midi track it is still ./rosegaren at cpu of ~45% and /usr/bin/X at ~30%. I also ran into a few other "bugs" which I'll try to recreate and write up this weekend and report back here. -crash referencing hexter -difficult file dialogs if can't find wav files -rosegarden[28456]: segfault at b910000 ip b60b1056 sp bf9969b8 error 4 in libc-2.10.1.so[b603c000+13e000] Thanks, Geoff On Fri, Feb 26, 2010 at 3:18 PM, Chris Cannam <ca...@al...> wrote: > On Fri, Feb 26, 2010 at 3:41 AM, Geoff King <gs...@gm...> wrote: >> On rosegarden 10.02.... How much CPU should rosegarden be using? I've >> got 5 tracks with some midi stuff that I recorded. It is sent to 3 >> different external keyboards. Nothing else going on at all. It is >> eating up ~50% CPU. > > That does sound high. > > CPU usage at the moment is a bit on the high side, but much of the |
From: Geoff K. <gs...@gm...> - 2010-02-27 20:16:50
|
The biggest factor is the size of the windows. Monitor is 1920x1200. If rosegarden window is large, say around 1600x900, then rosegarden/X CPU is about 49/43 If rosegarden window is small, but still almost usable, then rosegarden/X CPU is about 24/10 If rosegarden window is as small it goes (not really usable), then rosegarden/X CPU is about 13/1 On Sat, Feb 27, 2010 at 9:45 AM, Geoff King <gs...@gm...> wrote: > Hi Chris, > Playing around with it as you suggested, I haven't found any solution. > Here's some findings that might be of interest... |
From: Chris C. <ca...@al...> - 2010-02-27 20:26:07
|
On Sat, Feb 27, 2010 at 8:16 PM, Geoff King <gs...@gm...> wrote: > The biggest factor is the size of the windows. > Monitor is 1920x1200. > If rosegarden window is large, say around 1600x900, then rosegarden/X > CPU is about 49/43 > If rosegarden window is small, but still almost usable, then > rosegarden/X CPU is about 24/10 > If rosegarden window is as small it goes (not really usable), then > rosegarden/X CPU is about 13/1 Thanks, that's useful information. And is this with only the main window open? Chris |
From: Geoff K. <gs...@gm...> - 2010-02-28 03:08:47
|
On Sat, Feb 27, 2010 at 3:26 PM, Chris Cannam <ca...@al...> wrote: > On Sat, Feb 27, 2010 at 8:16 PM, Geoff King <gs...@gm...> wrote: >> The biggest factor is the size of the windows. >> Monitor is 1920x1200. >> If rosegarden window is large, say around 1600x900, then rosegarden/X >> CPU is about 49/43 >> If rosegarden window is small, but still almost usable, then >> rosegarden/X CPU is about 24/10 >> If rosegarden window is as small it goes (not really usable), then >> rosegarden/X CPU is about 13/1 > > Thanks, that's useful information. And is this with only the main window open? Yes - only the main window. CPU is even higher with a matrix or notation view open. ~70/70% |
From: Chris C. <ca...@al...> - 2010-03-01 17:57:37
|
On Sun, Feb 28, 2010 at 3:08 AM, Geoff King <gs...@gm...> wrote: >> Thanks, that's useful information. And is this with only the main window open? > > Yes - only the main window. CPU is even higher with a matrix or > notation view open. ~70/70% And finally (?), what happens if you run it with $ rosegarden -graphicssystem opengl ? Chris |
From: Geoff K. <gs...@gm...> - 2010-03-01 23:23:31
|
On Mon, Mar 1, 2010 at 11:26 AM, Chris Cannam <ca...@al...> wrote: > > And finally (?), what happens if you run it with > > $ rosegarden -graphicssystem opengl > It starts up but is not a usable GUI. Some menus work, but most of the main screen is not usable and the composition is not shown. It looks about how it would look at startup. However, some of the button do work, but nothing is visible. For example, file load dialog works, then click play button and it plays, but there is nothing graphical that would indicate it has loaded or started. CPU is variable, sometimes very high for rosegarden (90%), sometimes low, and X is low (<2). I can hear the composition play, but the graphics are non-responsive. Geoff |
From: Chris C. <ca...@al...> - 2010-03-02 11:28:11
|
On Mon, Mar 1, 2010 at 11:23 PM, Geoff King <gs...@gm...> wrote: [opengl] > It starts up but is not a usable GUI. Thanks. Since your replies have been informative so far, I hope you don't mind a couple more questions: In normal use (i.e. when not experimenting with opengl), is the CPU usage high only during playback, or is it high even when stopped? Is JACK running? I'm assuming that the CPU measurements you mention are via "top" rather than Rosegarden's own CPU meter? (The reason I ask is that Rosegarden's own meter aims to show total CPU usage system-wide, not just Rosegarden's own usage.) If you are building from SVN, or in a position to do so, I've committed some changes in trunk (revision 11834) which may make a difference to CPU usage during playback. Chris |
From: Geoff K. <gs...@gm...> - 2010-03-03 00:46:34
|
On Tue, Mar 2, 2010 at 6:28 AM, Chris Cannam <ca...@al...> wrote: > On Mon, Mar 1, 2010 at 11:23 PM, Geoff King <gs...@gm...> wrote: > [opengl] >> It starts up but is not a usable GUI. > > Thanks. Since your replies have been informative so far, I hope you > don't mind a couple more questions: I'm glad to help. > In normal use (i.e. when not experimenting with opengl), is the CPU > usage high only during playback, or is it high even when stopped? CPU is high only during playback = yes. It is low when stopped ~ 5% (reported by top) > Is JACK running? Yes. It has been running on most of the tests using Qjackctl > > I'm assuming that the CPU measurements you mention are via "top" > rather than Rosegarden's own CPU meter? (The reason I ask is that > Rosegarden's own meter aims to show total CPU usage system-wide, not > just Rosegarden's own usage.) > That is correct, rough averages running top. The meters in the bottom right also is high. > If you are building from SVN, or in a position to do so, I've > committed some changes in trunk (revision 11834) which may make a > difference to CPU usage during playback. Tried it. Revision: 11835 Still seeing similar CPU behaviour. It is hard to tell, but I think there may be a slight improvement. The last "large" size run was about 55/30 (~43 in rosegarden meter) |
From: Chris C. <ca...@al...> - 2010-03-04 11:11:36
|
On Wed, Mar 3, 2010 at 12:46 AM, Geoff King <gs...@gm...> wrote: > Tried it. Revision: 11835 > Still seeing similar CPU behaviour. It is hard to tell, but I think > there may be a slight improvement. Please try again with the latest (currently rev 11842). I'm fairly confident that this one should be much better behaved. Still a lot of work to do with the other editor windows, but the main canvas should be pretty quick now and I probably ought to look at fixing the progress dialogs before I go on to any other editors. Chris |
From: Geoff K. <gs...@gm...> - 2010-03-05 01:15:23
|
Hi Chris, There has been a noticeable improvement, but not dramatic. I found something new scenarios for you to consider... TEST1: Nine tracks with patterns all playing to different channels from #1 to #9 on the same external instrument. CPU 40% (rosegarden meter). That seems okay. TEST2: Nine tracks with patterns all playing to the same channel #1 on the same external instrument. CPU 75% (rosegarden meter). Why is this so much higher than Test1? Merging the Midi? TEST3: Similar to TEST2 in that all 9 tracks are on the same device/instrument channel #1. However, all are empty except for first track which has a pattern. Play it and the CPU will be much higher than if only the 1st track plays on that channel. CPU Averages 40-50% (rosergarden meter). If only the first track is assigned to channel #1 then CPU is low at less than 20%. This is the strangest one to me. Something about being on the same channel? All the blinking meters on empty tracks? My original examples that made me notice this had a few blank tracks that were assigned the same channel as other tracks with patterns. Otherwise, looking at "top" while playing my example large file.. - Xorg has gone down somewhat about 5% to 10%. this is the most noticeable change. - There seems to be a little more improvement in safe mode compared with fast - using $ rosegarden -graphicssystem opengl it does more than it did a few days ago but crashes upon loading projects or playing. Hope this helps. Geoff > > Please try again with the latest (currently rev 11842). I'm fairly > confident that this one should be much better behaved. Still a lot of > work to do with the other editor windows, but the main canvas should > be pretty quick now and I probably ought to look at fixing the > progress dialogs before I go on to any other editors. |
From: Chris C. <ca...@al...> - 2010-03-05 10:17:49
|
On Fri, Mar 5, 2010 at 1:15 AM, Geoff King <gs...@gm...> wrote: > Hi Chris, There has been a noticeable improvement, but not dramatic. Hm, that's strange and disappointing. I really thought I'd found the cause there. > TEST1: Nine tracks with patterns all playing to different channels > from #1 to #9 on the same external instrument. CPU 40% (rosegarden > meter). That seems okay. Well, comparatively perhaps -- but that actually seems really high to me already. > TEST3: Similar to TEST2 in that all 9 tracks are on the same > device/instrument channel #1. However, all are empty except for first > track which has a pattern. Play it and the CPU will be much higher > than if only the 1st track plays on that channel. CPU Averages 40-50% > (rosergarden meter). If only the first track is assigned to channel > #1 then CPU is low at less than 20%. This is the strangest one to me. > Something about being on the same channel? All the blinking meters on > empty tracks? That is a puzzle. I will investigate those meters, since they're the only GUI element that differs between the two examples (right?)... it would be odd if they were the cause, but it's not impossible. Chris |
From: Julie S <msj...@ya...> - 2010-03-05 14:55:44
|
Hello Chris, I just tried the latest svn and I do see a big improvement on my dual core system. At least a 10% improvement. I tried several midi pieces and played them back. Now I just plopped in an extra 2Gig of memory yesterday. So maybe my assessment isn't fair. But, I know I was not swapping out to HDD before when I was running RG before. One thing that I notices is that the zoom factor plays a big role in my CPU usage. At 100% or greater scales the CPU usage is up on playback. But if I zoom to say 10% or 20%. I get a dramatic drop in CPU usage (a 15% to 20% drop). "Bogus Surf Jam" is a good example. Try it yourself. You'll see what I'm talking about. My educated guess is that updating the position indicator line is CPU intensive. So maybe if we looked at that a bit, we might find some efficiencies. Just some thoughts...unfortunately no time to investigate. Sincerely, Julie S. |