|Summary:||timidity++-2.13.* has much higher cpu usage than 2.12.0|
|Product:||Gentoo Linux||Reporter:||Ernst Bachmann <e.bachmann>|
|Component:||Current packages||Assignee:||Jeremy Huddleston (RETIRED) <eradicator>|
|Package list:||Runtime testing required:||---|
Description Ernst Bachmann 2004-11-24 03:21:11 UTC
While timidity++-2.12.* worked fine for me on serveral aged systems (~ Amd Duron 600, Pentium III - 850 and similar) (in fact, it didn't even use notable ammounts of CPU time on those systems, maybe 10% at most) all 2.13 versions I tested this far are completely unusable on those systems. CPU load increases to 100% and the sound still skips and jumps when trying to play a midi there. I couldn't spot any changes in Timidities changelog that would justify such a dramatic increase in CPU usage, but till (if ever) it is fixed there, it would be great to keep the 2.12 ebuilds arround and have a 2.12 ebuild with included "timidity-update" script. Reproducible: Always Steps to Reproduce: I tested timidity-2.13.* on a AMD-Duron-600 Desktop, 384MB Ram, and a Pentium-III-850 Notebook, 256MB Ram, nptl-glibc. It was unusable on both. However, it worked fine on a P4 with 2.66GHz...
Comment 1 Jeremy Huddleston (RETIRED) 2004-11-26 12:22:38 UTC
please provide the output of 'emerge --info' maybe we can find the culprit...
Comment 2 Tommy Li 2004-11-27 15:11:03 UTC
Comment 3 Ernst Bachmann 2004-11-29 01:44:42 UTC
Comment 4 Jeremy Huddleston (RETIRED) 2004-11-29 02:31:35 UTC
so is timidity just slow when you use it with alsa midi? What about when you convert to a wav file? Can youu try media-sound/alsa-driver-1.0.7-r1 on both systems to see if the updated alsa drivers break/fix it?
Comment 5 Ernst Bachmann 2004-11-29 05:35:06 UTC
Ok, I did some timing. First I selected a MIDI file with only 9 Tracks, which was actually playable on both systems (with only one or two skips on the slow one). I played it with "time timidity filename.mid", iow, without using the alsa sequencer port, but using the alsa output. Playing time: ~320 seconds. Notebook: real 5m22.765s user 3m13.235s (about 60% CPU load) sys 0m0.881s Desktop: (about 5 or 4 times faster) real 5m19.549s user 1m9.167s (about 20% CPU load) sys 0m0.437s About what I expected... the system is faster, thus less cpu time spent... When playing the same MIDI with "kmid" over the alsa midi port, and running timidity in sequencer mode, I get about the same figgures (50-70% CPU load) when watching the timidity demon process in "top" When using "-Ow" to generate a .wav file, the time spent is about the same. Now: # emerge =timidity++-2.12.0-r3 on both systems... takes a while... ok, same patchsets, same timidity.cfg, same midi file, again, timing from shell: Notebook: real 5m20.356s user 0m13.542s (about 5% CPU load) sys 0m0.503s Desktop: real 5m19.200s user 0m3.031s (about 1% CPU load) sys 0m0.180s Now thats quite a bit faster. And I couldn't hear a difference in sound quality, but I was only using cheap headphones, so that doesn't mean much.
Comment 6 Jeremy Huddleston (RETIRED) 2004-11-29 12:02:52 UTC
ok... thanks for the testing. I was assuming the cpu usage on the P4 was normal, but it looks like this problem is just not felt on the P4 ;) Can you report this info to the timidity devs? They should be able to better help... http://timidity-docs.sourceforge.jp/cgi-bin/kagemai-en/guest.cgi?project=timidity-bugs-en&action=top Please send me a link when you do, so I can follow the progress of the bug.
Comment 7 Ernst Bachmann 2004-11-30 01:17:41 UTC
Bug posted on timidity dev site. http://timidity-docs.sourceforge.jp/cgi-bin/kagemai-en/guest.cgi?project=timidity-bugs-en&action=view_report&id=39 Thanks for your help. I'll just copy the 2.12 ebuild into my portage overlay dir and mask out the 2.13 versions on my system for now ;)
Comment 8 Ernst Bachmann 2004-12-08 06:02:30 UTC
It turned out that timidity 2.13 changed the default values for some options responsible for sound quality, thus increasing CPU load. Changing the resampling mode (-EFresamp) and playing with the reverb+chorus parameters (-EFreverb/-EFchorus) lowered those requirements to about the same that 2.12 had. Would be nice to see some hints in /etc/conf.d/timidity about cpu intensive options in the next release, though.
Comment 9 Jeremy Huddleston (RETIRED) 2004-12-08 06:29:35 UTC
could you post such hints here and repoen the bug? I'll include them.
Comment 10 Ernst Bachmann 2004-12-17 01:40:31 UTC
a Post on the timidity bugtracker, which sums up the changes between 2.12 and 2.13 quite nicely: ---- cut ------ Did the default rate used to be 32000 in 2.12.0? I seem to remember it was. Since 2.13.x defaults to 44100, that's a 1.37x slowdown right there. Use -s 32000 to lower the sampling rate if you really need to. -EFresamp=d is not a good idea, as it disables interpolation all together, which is worse than the quality of 2.12.0. 2.12.0 defaulted to linear interpolation, so -EFresamp=l would give you the same resampling quality and roughly the same interpolation speed as 2.12.0. I say "roughly" because the interpolation routines were changed from macros to function pointers, which have a very small impact on speed, but makes for much much cleaner code and also give the ability to change interpolation modes on the fly. -EFresamp=L will be a little better quality (4-point interpolation), but a bit slower. -EFresamp=g is the highest quality interpolation mode, and is the default in 2.13.x, defaulting to -N 25 (26-point interpolation). To use a quality higher than 4-point (-N 3) but faster than the default (-N 25), use -EFresamp=g and choose a -N value somewhere in between, preferably an odd number. The reverb engines have changed since 2.12.0, and I don't know how the speeds compare to the old reverb engine. The "global" reverb modes are the fastest, since they apply a single reverb globally, rather than a separate reverb to each channel. I typically use - EFreverb=g,42 (global normal reverb at level 42) or -EFreverb=G,21 (global Freeverb at level 21). You should tweak the reverb level settings to whatever you think sounds the best, but definately use one of the global reverbs if speed is an issue. -EFchorus=s is very nearly the same as the old -EFchorus=2 mode, and should run at roughly the same speed as the old -EFchorus=1 mode (the 2.12.0 default) since they both work(ed) by doubling the number of voices. -EFchorus=1 has been replaced by -EFchorus=n, which uses an entirely new DSP chorus engine instead of doubling the number of voices like was done in 2.12.0. I would guess that -EFchorus=n might be faster, since it doesn't have to interpolate and mix 2x the number of voices, but I never have compared the speeds. Choose whichever one you think sounds the best, then lower the -N value or change the -EFresamp settings to whatever your computer can handle. -f toggles "fast decay" which will cause all notes to decay 2x faster after NOTEOFF. I personally prefer fast decay, plus it runs faster. The original behavior, back in the 0.2x days (almost a decade ago, wow how time flies), was that fast decay was enabled by default, and -f was used to make voices decay 2x slower to create a pseudo-reverb effect. When timidity continued development after Tuukka Toivonen was no longer maintaining it, the default was changed to disable fast decay by default (I don't know the reason for this dicision, it was before I started contributing). Actual GUS hardware decay rates varry depending on the number of voices currently being played (!) so that neither mode is actually "correct". Smaller numbers of voices decay faster, while larger numbers of voices decay slower, since the decay calculations in the hardware take more time to iterate over a larger number of voices. "fast decay" should be closest to the rate you would get on a real GUS if a single instrument is playing, and is therefore, IMHO, the mode that should be used for GUS instruments. I seem to remember either the ancient 0.2x documentation or code comments also saying that "fast decay" should be closer to a real GUS, and that non-fast decay should only be used to create a pseudo-reverb effect (which was later replaced by true pseudo-reverb effects, which were further replaced by true reverb engines). Use -f for speed, or if you are using GUS pats. To see if your computer can handle the current settings, run timidity in ncurses console mode and watch the % audio queue. If it ever drops to <= 100%, you've chosen settings that are too slow for proper realtime playback and some popping noises may occur. I have a 1.53 GHz Athlon, and even the most demanding of my MIDI files play just fine with the following (NOTE: Windows requires %% for % signs, and I'm using Windows. It also requires anything with an = to be enclosed in ""): "-EFresamp=g" -N 25 -q 5/200%% -m 3000 "-EFns=0" "-EFchorus=2" "- EFreverb=4,21" -s 44100 -f -int -m 5000 is the 2.13.x default, rather than -m 3000, but -m 5000 would only cause a bit of a slowdown during pedal sustains, and those aren't usually very common, so choose whatever you think sounds best for pedal sustains. I don't like the sound of the new default noiseshaping in 2.13.x, which is why I use -EFns=0. 2.12.0 defaulted to -EFns=0, so that may also be a source of slowdown in 2.13.x. Forgive my use of the deprecated 1-4 modes for reverb and chorus; I've just found it difficult to change to the new letters over the years, plus the src code converts all the letters into the old numbers anyways and that is how I always think about them :)