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...
please provide the output of 'emerge --info' maybe we can find the culprit...
I have the same symptoms (100% cpu, skipping), and I'm on an Athlon 2400! Here is my "emerge info": Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.4.2, glibc-2.3.4.20041102-r0, 2.6.9-nitro4 i686) ================================================================= System uname: 2.6.9-nitro4 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.6.6 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib acpi alsa apm arts audiofile avi berkdb bitmap-fonts cdparanoia cdr crypt cups dba directfb dvd encode ethereal f77 fam flac foomaticdb fortran gd gd-external gdbm gif gpm gtk gtk2 imagemagick imlib ipv6 java javascript joystick jpeg junit kde libg++ libwww mad mikmod mmx motif mpeg mysql ncurses network nls nowin nptl oggvorbis openal opengl oss pam pcre pdflib perl png python qt quicktime readline samba sdl slang speex spell sqlite sse ssl stroke svga tcltk tcpd tetex tiff truetype unicode wifi x86 xft xine xml xml2 xmms xv zlib"
Here's my emerge --info, most apparent differences would be: 2.6.8 kernel vs. 2.6.9 Did they change the alsa MIDI interfaces or something there? nptl glibc vs !nptl. timidity does link against libpthread, so nptl could be the culprit. Did they change some thread handling code from 2.12 -> 2.13 in timidity? -------------------------------------------------------------- Pentium4 - 2.66Ghz System: (where timidity++-2.13 works fine) # emerge --info Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.8-gentoo-r7 i686) ================================================================= System uname: 2.6.8-gentoo-r7 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz Gentoo Base System version 1.5.3 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.19-r1,sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms userpriv usersandbox" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://www.gigaload.org/gentoo.org/ ftp://gentoo.inode.at/source/ http://gentoo.inode.at/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acpi acpi4linux alsa arts artswrappersuid avi ba-completion berkdb bitmap-fonts bluetooth bonobo cddb cdr codecs crypt cups dga dmx dvd encode f77 fam fbcon flac foomaticdb fortran gcj gdbm ggi gif gnokii gpm gtk gtk2 gtkhtml guile imagemagick imlib jack java jpeg junit kde libg++ libwww mad matroska mikmod mmx mng motif mozilla mpeg mplayer ncurses nls nvidia offensive oggvorbis opengl oss pam pdflib perl png python qt quicktime readline rtc scanner sdl slang smime speex spell ssl svg tcltk tcpd tetex theora tiff timidity truetype truetype-fonts type1-fonts unicode usb x86 xine xml xml2 xmms xosd xrandr xv xvmc zlib" # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.66GHz stepping : 7 cpu MHz : 2666.656 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips : 5292.03 (No Hyperthreading enabled) ----------------------------------------------------------------------- Pentium3 - 850Mhz System (Where Timidity++-2.13 doesn't work at all) # emerge --info Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r4 i686) ================================================================= System uname: 2.6.9-gentoo-r4 i686 Pentium III (Coppermine) Gentoo Base System version 1.5.3 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -mcpu=pentium3 -pipe " CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/fax /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi//var/qmail/control /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/X11/xkb /etc/gconf /etc/terminfo /usr/X11R6/lib/X11/xkb /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -mcpu=pentium3 -pipe " DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms userpriv usersandbox" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp6.uni-muenster.de/pub/linux/distributions/gentoo http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/localhome/temp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acpi acpi4linux alsa apm arts artswrappersuid avi berkdb bitmap-fonts bluetooth cdparanoia cdr codecs crypt cups curl dga dvd encode f77 fam fbcon firebird flacflash fortran gd gdbm gif gimp gphoto2 gpm gstreamer gtk gtk2 iconv imagemagick imap insecure-drivers irda java javascript jpeg junit kde ldap libg++ libwww lm_sensors mad matroska mikmod mime mmx mng motif moznocompose moznoirc moznomail mozsvg mpeg mplayer mule music ncurses nis nls nptl odbc oggvorbis opengl pam pcmcia pcre pdflib perl pic png pnp python qt quicktime readline rtc ruby samba sapdb scanner sdl slang smime speex spell sse ssl svg tcltk tcpd tetex theora tiff timidity truetype unicode usb userlocaleswmf x86 xine xinerama xml2 xmms xv xvmc zlib" # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 852.155 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1691.64
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?
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.
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.
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 ;)
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.
could you post such hints here and repoen the bug? I'll include them.
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 :)
