10 Jun
2004
10 Jun
'04
5:13 p.m.
Greetings:
Can someone explain why TiMidity eventually hogs the CPU at 95% or
more after running for a while (like 12 hours or more) ? I'm talking
about hogging the chip while TiMidity is idling, not playing. I'm using
it as a softsynth, it works well, but even in the latest version its CPU
usage just soars. Here's how I'm invoking 2.13.0 :
timidity -iA -B2,8 -c /home/dlphilp/timidity.cfg -A100 -Oj
-EFreverb=0 -EFchorus=0
Takashi: Obviously I spoke too soon in my earlier message. I just
looked at top again and saw that TiMidity was eating up 96% of the CPU. :(
Best,
dp
10 Jun
10 Jun
5:49 p.m.
Dave Phillips wrote:
Greetings:
Can someone explain why TiMidity eventually hogs the CPU at 95% or more
after running for a while (like 12 hours or more) ? I'm talking about
hogging the chip while TiMidity is idling, not playing.
I'd guess that it is actually playing -- busy running through all its
calculations on an empty input midi stream and playing silence. But
I don't understand why it would hog more and more over time. Maybe
it's channel filters that accumulate. Those are ordinarily
reinitialized at the beginning of each midi file, but when it's
a server, perhaps there are no new beginnings, and if a filter
is ever used on a channel, it persists to the end of server time.
Filters take lots of computation.
Greg
11 Jun
11 Jun
7:32 a.m.
Hi Dave, Takashi!
I've got timidity up and running now, as a server under OSS. Made me
self a new option to read directly from /dev/sequencer2 (The
documentation says the input format should be similar to /dev/sequencer,
but that's wrong.)
The first note I play actually happens, and resembles an acoustic piano
with a bit of wobbly reverb. So far so good ...
The problem is that it stops rendering as soon as I release the note and
then only renders when there is new midi-input (as in massaging the
modulation wheel like a mad man ...). I have tried turning active
sensing ON on my keyboard to no avail.
Then I started to look further into the sources in search for the actual
synthesizer. There is some 3MB of cross-platform C-code and headers, and
most of it is not what I'm looking for.
So far I have only localized the soundfont loader and I am currently
reading up on the struct that defines the format. If I can find (or if
you can help me find?) the parts that actually assigns and renders a
note, then I should be able to write a new CPU-friendly voice-assigner
The goal would be to pruduce something like a tmdt--. That is to say:
Timidity++ unbloated, a module which only includes the stuff needed to
run as a softsynth under Linux.
So, where is the damned synthesizer? :)
mvh // Jens M Andreasen
On tor, 2004-06-10 at 21:47, Dave Phillips wrote:
Greetings:
Can someone explain why TiMidity eventually hogs the CPU at 95% or
more after running for a while (like 12 hours or more) ? I'm talking
about hogging the chip while TiMidity is idling, not playing. I'm using
it as a softsynth, it works well, but even in the latest version its CPU
usage just soars. Here's how I'm invoking 2.13.0 :
timidity -iA -B2,8 -c /home/dlphilp/timidity.cfg -A100 -Oj
-EFreverb=0 -EFchorus=0
Takashi: Obviously I spoke too soon in my earlier message. I just
looked at top again and saw that TiMidity was eating up 96% of the CPU. :(
Best,
dp
9:22 a.m.
Hi,
On Friday 11 June 2004 11.26, Jens M Andreasen wrote:
Hi Dave, Takashi!
I've got timidity up and running now, as a server under OSS. Made me
self a new option to read directly from /dev/sequencer2 (The
documentation says the input format should be similar to /dev/sequencer,
but that's wrong.)
The first note I play actually happens, and resembles an acoustic piano
with a bit of wobbly reverb. So far so good ...
The problem is that it stops rendering as soon as I release the note and
then only renders when there is new midi-input (as in massaging the
modulation wheel like a mad man ...). I have tried turning active
sensing ON on my keyboard to no avail.
Then I started to look further into the sources in search for the actual
synthesizer. There is some 3MB of cross-platform C-code and headers, and
most of it is not what I'm looking for.
So far I have only localized the soundfont loader and I am currently
reading up on the struct that defines the format. If I can find (or if
you can help me find?) the parts that actually assigns and renders a
note, then I should be able to write a new CPU-friendly voice-assigner
The goal would be to pruduce something like a tmdt--. That is to say:
Timidity++ unbloated, a module which only includes the stuff needed to
run as a softsynth under Linux.
So, where is the damned synthesizer? :)
It's in there! ;-}
Now, you might have already tried Fluidsynth, but I thought I would mention it
for completeness.
Fluidsynth is also a soundfont player which "might" be more aimed at realtime
synth.
It has it's own sets of problems though, none that really matter to me though,
I think it's an excellent synth.
/Robert
ps.
As for the CPU hogging, fluidsynth had a problem earlier when the reverb was
enabled. When there was little or none signal into the reverb it went totally
bonkers and consumed pretty much all cpu (a denormal problem I seem to
remember).
So the obvious question is, when timidity consumes all cpu, is the reverb
enabled?
ds.
mvh // Jens M Andreasen
<...>
--
http://spamatica.se/music/
12:39 p.m.
On fre, 2004-06-11 at 13:10, Robert Jonsson wrote:
...
So, where is the damned synthesizer? :)
It's in there! ;-}
Now, you might have already tried Fluidsynth, but I thought I would mention it
for completeness.
Fluidsynth is also a soundfont player which "might" be more aimed at realtime
synth.
Yep! This exactly what I was looking for, thankyou!
It is not the same soundfonts as timidity, but there seems to be lots of
emu compatible sounds around to get going for a while :)
It has it's own sets of problems though, none that really matter to me though,
I think it's an excellent synth.
/Robert
ps.
As for the CPU hogging, fluidsynth had a problem earlier when the reverb was
enabled. When there was little or none signal into the reverb it went totally
bonkers and consumed pretty much all cpu (a denormal problem I seem to
remember).
So the obvious question is, when timidity consumes all cpu, is the reverb
enabled?
ds.
mvh // Jens M Andreasen
<...> 
10:55 a.m.
At Thu, 10 Jun 2004 15:47:07 -0400,
Dave Phillips wrote:
Greetings:
Can someone explain why TiMidity eventually hogs the CPU at 95% or
more after running for a while (like 12 hours or more) ? I'm talking
about hogging the chip while TiMidity is idling, not playing. I'm using
it as a softsynth, it works well, but even in the latest version its CPU
usage just soars. Here's how I'm invoking 2.13.0 :
timidity -iA -B2,8 -c /home/dlphilp/timidity.cfg -A100 -Oj
-EFreverb=0 -EFchorus=0
Takashi: Obviously I spoke too soon in my earlier message. I just
looked at top again and saw that TiMidity was eating up 96% of the CPU. :(
If it constantly hogs CPU even without playing noes, it must be a
bug. My rough guess is that the sample position goes back to 0 or
negative due to the integer overflow.
Are you keeping the MIDI connection for this long time?
What happens if you once disconnect from timidity?
Takashi
14 Jun
14 Jun
12:04 p.m.
Takashi Iwai wrote:
If it constantly hogs CPU even without playing noes, it
must be a
bug. My rough guess is that the sample position goes back to 0 or
negative due to the integer overflow.
Are you keeping the MIDI connection for this long time?
What happens if you once disconnect from timidity?
Hi Takashi:
It seems that the problem is non-existent if TiMidity is not connected
to anything. I ran it for about 8 hours without connecting it to any
other software, CPU usage remained very low. Btw, I've upgraded to
version 2.13 now.
Also btw, thanks to everyone who wrote with observations and suggestions !
Best,
dp
11 Jun
11 Jun
11:27 a.m.
New subject: [linux-audio-dev] Timidity++ in surround
I've patched up Timidity++ to play in 4/6 channel surround
using the Alsa driver on Linux (or perhaps other systems
with Alsa). Source files to replace those of the current
CVS version of Timidity++ are in
ftp://ling.lll.hawaii.edu/pub/greg/Timidity51.tgz
The included Alsa output driver will also handle 2-channel
24 bit output. Probably only works with a recent version
of Alsa.
Greg
12 Jun
12 Jun
1:26 a.m.
New subject: [linux-audio-dev] 5.1 wave files
I've made some utility programs for breaking up 6 channel
wave files into stereo and mono wave files, and going the
other way -- assembling 6 channel waves from stereo and
mono wave files. There's also a wave file player that
works better than aplay for playing 6 channel waves using
Alsa. The programs are based on libsndfile and are in
ftp://ling.lll.hawaii.edu/pub/greg/surround-utils-0.0.2.tar.gz
Also there are hacked files for ac3dec which add the option
of saving decoded ac3 as a wave file.
Greg
15 Jun
15 Jun
10:39 p.m.
New subject: [linux-audio-dev] Surround panning algorithm
I need to do surround panning for a couple of applications.
The following is what I have so far. it's not principled
or analytical --- I just made it up this morning off the
cuff. I'm hoping some of you will have suggestions. Pointers
to sample code for better versions would be nice.
/*
* "pan" is midi pan, 0 (left) to 127 (right)
* "speaker" is 0 (left surround), 32 (left front),
* 64 (center), 95 (right front), 128 (right surround)
* "separation" is 95 for 4-channel surround (left
* front and right front taper down to 0 amplitude
* at right pan=127 and left pan=0, respectively).
* and is 64 for 6-channel surround (center tapers
* down to 0 amplitude at left and right).
*
* Returns amplitude 0-127 for requested speaker.
*/
static int panf(int pan, int speaker, int separation)
{
int val;
val = abs(pan - speaker);
val = (val * 127) / separation;
val = 127 - val;
if (val < 0) return 0;
if (val > 127) return 127;
return val;
}
Greg
7660
days inactive
7665
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
5 participants
participants (5)
-
Dave Phillips -
Greg Lee -
Jens M Andreasen -
Robert Jonsson -
Takashi Iwai