9 Dec
2003
9 Dec
'03
8:50 a.m.
OK, thanks, i will try this tonight.
--
Gerrit
When i use
timidity in alsa seq mode with a sequencer like muse or
seq24, the timing is not very good. If i use fluidsynth the
timing is much better. I would like to use timidity though, because
of its support for the Midi Tuning Standard.
Are others seeing this too? Are there any options or
other ways to improve the timing for timidity?
For me it's the other way around, I can't use fluidsynth on my
old AMD 1.2Ghtz machine whereas the Timidity from debian/unstable
works fine. Perhaps you need a -B2,8 arg, makes all the difference
for me and my SBlive card. 
9 Dec
9 Dec
9:33 a.m.
New subject: [linux-audio-user] Timidity vs. Fluidsynth
Greetings:
Last night I decided to test TiMidity against Fluidsynth. The results
were interesting.
Here's the test scenario :
run Sequencer Plus Gold in dosemu
route MIDI output to ALSA virmidi module
start TiMidity with 'timidity -iA -B2,8 -Os -c timidity-sf2.cfg
-EFreverb=0 -EFchorus=0'
start JACK (qjackctl) then start qsynth
connect virmidi to either TiMidity or Fluidsynth (qsynth) via
kaconnect
Both synths used the same soundfont (FluidR3). The output from qsynth
was subjectively more to my liking, but I had a persistent problem with
noise, as though periodically the synth output would "fall off the
rails", resulting in severe aliasing. It eventually corrects itself but
until I resolve this problem I would not use qsynth for a production
run. OTOH TiMidity just works fine. The only problem I have with it is
that I'm now rather spoiled by what I take to be the better filters of
Fluidsynth. TiMidity's output was comparatively harsh, but of course I
can modify it with outboard gear (or a LADSPA plugin ?) if necessary.
I tested the synths separately and in unison. No radical timing errors
occurred and intonation was fine. I'll test Fluidsynth without the GUI
today to determine whether the qsynth GUI contributes to the audio
breakup. Meanwhile I welcome any comments or suggestions regarding this
test.
Oh yeh: I'm running a PlanetCCRMA kernel 2.4.22 patched for
low-latency, ALSA 0.9.6, TiMidity 2.11.3, and qsynth 0.0.2 (fluidsynth
1.0.3). JACK version is 0.91.1 and qjackctl is version 0.1.3.
Best regards,
== dp
11:18 a.m.
New subject: [linux-audio-user] Timidity vs. Fluidsynth
On Tue, 9 Dec 2003 11:41 pm, Dave Phillips wrote:
Both synths used the same soundfont (FluidR3). The
output from qsynth
Seems like FluidR3 is the most likely candidate for a quasi-reference
soundfont.
was subjectively more to my liking, but I had a
persistent problem with
noise, as though periodically the synth output would "fall off the
rails", resulting in severe aliasing. It eventually corrects itself but
until I resolve this problem I would not use qsynth for a production
run. OTOH TiMidity just works fine. The only problem I have with it is
that I'm now rather spoiled by what I take to be the better filters of
Fluidsynth. TiMidity's output was comparatively harsh, but of course I
can modify it with outboard gear (or a LADSPA plugin ?) if necessary.
I have an Athlon 1.2Ghtz machine and I think it's not powerful
enough to run fluidsynth whereas Timidity 2.11.2 (Debian/unstable)
works fine both from a shell and in alsaseq mode. The latest Timidity
from CVS seems to sound different, perhaps better, but it struggles to
keep up in alsaseq mode with muse whereas v2.11.2 hangs in. I suspect
a 2Ghtz+ machine would work fine (for fluidsynth).
What Ghtz machine are you using for your tests ?
(I don't even bother with jack and ladspa or gui stuff, except muse)
--markc
1:03 p.m.
New subject: [linux-audio-user] Timidity vs. Fluidsynth
Mark Constable <markc(a)renta.net> writes:
Seems like FluidR3 is the most likely candidate for a
quasi-reference
soundfont.
Can anyone tell me where to find FluidR3 in a Linux-friendly format
(i.e. not sfArk)?
I am not interested enough to set up wine just to decode the file. Of
course, a native Linux sfArk decoder would make a wonderful project
for some worthy LAD-der.
--
joq
7708
days inactive
7708
days old
linux-audio-user@lists.linuxaudio.org
3 comments
4 participants
participants (4)
-
Dave Phillips -
Gerrit Niestijl -
Jack O'Quin -
Mark Constable