I'm potentially in the market for a new box before end of year. Has anyone
found anything to show whether Athlon64 (or the high-end FX line) are worth
it for audio? Assume some legacy audio code under legacy OS :-/
Benno Sennoner and I were discussing today on IRC about
the usual fixed point vs floating point (regarding to some resampling code)
We developed some tests and ran them on a variety of computers.
It would be interesting if ladders here could run them on different computers
(and specially non x86, like amd64. or the Gx processors) so we can
see what performance can we expect on each , and how things
seem to be shaping for the future. It will also be a key factor
on how our projects will develop in the future.
The code is available at:
http://reduz.dyndns.org/resamp_fixp.c // fixed point version
http://reduz.dyndns.org/resamp_float.c // floating point version, portable
http://reduz.dyndns.org/resamp_float_fistl.c // X86 VERSION ONLY!! Uses fistl
The results dont mean just int vs float performance. They
also test for float->int conversion, which is common
in most algorithms that work with buffers. It is a linearly
interpolated resampling with volume control.
please use GCC options -
-O3 -ffast-math -march=<yourcpu> so it's a fair comparison
results from other compilers is also appreciated!
Here's some results for reference
vendor_id : AuthenticAMD
model name : AMD-K6(tm) 3D processor
cpu MHz : 412.508
cache size : 64 KB
flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips : 822.47
resamp_fixp - 0m8.460s
resamp_float_fistl - 0m27.390s
vendor_id : AuthenticAMD
model name : AMD Duron(tm) Processor
cpu MHz : 951.701
cache size : 64 KB
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1900.54
resamp_float - 0m11.180s
resamp_float_fistl - 0m5.810s
resamp_fixp_optimized - 0m2.790s
Benno gave me some results:
Intel p4 1800 celeron
resamp_float_fistl - 4.00user
resamp_fixp - 4.51user
VIA nehemiah 1GHz
resamp_float_fistl - 0m21.079s
resamp_fixp - 0m7.129s
Some results on SPARC:
2x 125MHz HyperSPARC
resamp_fixp - user 2m59.010s
resamp_float - user 0m44.290s
(float faster! :)
Intel 2.4 GHZ P4:
resamp_float - 0m3.440s
resamp_float_fistl - 0m2.960s
resamp_fixp - 0m1.450s
1.25GHz G4 (laptop)
resamp_float - 0m11.170s
resamp_fixp - 0m2.130s
Conclusions SO FAR.
My own conclusions about the subject is that the float -> int conversion is
STILL the biggest bottleneck on most common architectures. And until this is
sorted out, fixed point is still the best solution for some specific cases,
and I dont see any problem mixing it with floating point code. If you look
at that algorithm closely in the source, you could replace "counter/
for purely fixed point values, and do the rest (managing the samples) in
float. This will undoubly speed it up..
I've recently been learning to use JACK, and I had a look around for
some kind of introductory article. I couldn't find one, so I wrote
the tutorial I would have wanted, as I learnt.
The tutorial is here:
Please have a look, make suggestions. Flames are fine, too. Let me
know if I've made some huge error. Or maybe I'm not doing things
the best way? Whatever, let me know.
If this is well received, I'll write about more advanced topics as I
get to them - mixing, the transport, threading without blocking the
process callback, etc.
I'll probably be asking a lot of questions later on, especially
about best practise.
I've read somewhere that it is not possible that threads write different data to /dev/dsp.
But how does Cheesetracker, for example, make it then?
Verpassen Sie keine eBay-Auktion und bieten Sie bequem
und schnell über das Telefon mit http://www.telefonbieten.de
Ihre eMails auf dem Handy lesen - ohne Zeitverlust - 24h/Tag
eMail, FAX, SMS, VoiceMail mit http://www.directbox.com
This is the last reminder for anyone interested in presenting at the
audio mini-conference at Linux.Conf.Au, Monday January 12 2004.
Submissions are due at the end of this week (Fri 31 Oct), details at:
It's turning out to be an excellent day of LAD hacking and jamming,
with a full day of presentations lined up and an evening's playing at
a local bar in the planning. The full schedule will be released next
A mailing list has been set up for general discussions and info about
the mini-conference, info for subscribing is at:
To register for this mini-conference you MUST register for the main
Linux.Conf.Au conference. Unfortunately audio-miniconf-only
registrations are not available, sorry. Nevertheless you will not
be disappointed: the main conference has four parallel tracks of
tutorials and paper presentations running from Wednesday to
Saturday, covering everything from programming VR applications
to writing user-level device drivers; check it out and drool:
Lastly ... if Tim Mayberry or Nick Mainsbridge could please drop
me an email, or if anyone could give me current contact details for
either of them, that would be much appreciated :)
a new, completely redone version of my valve-inspired preamp plugin is
up. improvements over the predecessor include:
* smoother distortion; clipping kicks in veeery gently
* a better 'gain' knob model and balance between input and output
* initial hi-pass filtering now part of the unit
* gentle mid-range frequency boost
* closer matching of the original circuit's harmonic distortion
* 4x oversampling at 44-48 kHz sample rates
more info and the plugin sources at http://quitte.de/dsp/preamp.html
i was thinking about latencies of softsynths and how cubase vst handles
this when playing back recorded midi tracks as opposed to playing the
softsynth directly. I'm talking about the vst-softsynths here. not the
ones that get controlled via usual midi ports.
It seems that during playback of a prerecorded midi track cubase vst
knows the latency of the softsynth and and arranges for that so that the
softsynth is really tight [no offset to other recorded audio material].
This is, of course, only possible because the midi signal if routed
vst-internally is handled different than midi that gets sent out.
I suppose that todays available audio/midi-sequencer support midi in a
form that it is synchronized to the latency of the audio signal that is
sent out. So, if the audio signal takes 2*128/44100s [2 buffers a 128
frames] to reach the ear of the user, then the prerecorded midi signal
is delayed this exact amount of time, because midi signals is supposed
to be of zero latency. And for external hardware synthesizers this is
pretty much true. This way prerecorded audio and midi tracks are nicly
synchronised during playback.
Now, for the case of a sofstsynth this scenario doesn't fit, because the
synth is not zero latency. This means that a "tight" midi track is
audible with the softsynths output latency.
Now, Jack is really an audio server but it could also be used to
communicate the latency of the softsynth to the Audio/Midi Sequencer. I
know there's calls to get the output latency of physical output ports.
But it would be nice to have calls to ask for the physical output
latency of clients [this value can be different for different clients -
maybe with different output devices].
This way, the audio/midi-sequencer could ask jack for a list of clients
and offer this choice to the user who then can select which midi tracks
correspond to which softsynth. The Sequencer could then send the midi
events a tad bit earlier [the output latency of the softsynth].
What do you think? I have no insight into the implementation details of
jack, so i don't know how possible this scenario is and if it fits with
Cheesetracker is a portable Impulse Tracker clone. It supports all the main
Impulse Tracker and FastTracker/SoundTracker features, plus many more.
It is licensed under the GNU Public License. It runs under
Linux/BSDs, MacOSX(QT/Mac or Qt/X11), or Win32(Cygwin).
It can be obtained at http://cheesetronic.sf.net
For those unfamiliar with trackers, this is basically an
all-in-one sequencer/sampler/sample editor/mixer/fx processor bundle,
wich provides fast and flexible means for professional grade
Including in the release are tutorials and documentation.
Volunteers to help to better documment it would
be highly appreciated.
The ChangeLog for this release follows:
-Removed sample mode (Scream Tracker 3 mode) as It's obsolete and not needed
for backwards compatibility.
-Instruments are now layered and can perform up to 4 simultaneous voices with
individual parameters each.
-Added an effect buffers system. Instruments are now routed to custom buffers
(each with individual effect chains), which can also re-route to other
buffers. This allows to create very complex effect routes for realtime
-Effect buffers are "process on demand", which means they are smart enough to
notice when they are doing nothing, thus disabling themselves.
-Added a few internal effects: Amplifier, Clipping/Distortion, Recursive Delay
Line, Stereo Enhancer, Chorus and Reverb.
-Added a LADSPA effect source plugin. LADSPA plugins can be added to the
-Created new file formats that save all the new features: .CT (CheeseTracker
Module) .CI (Cheesetracker Instrument) and .CS (CheeseTracker Sample)
-Added preview to the sample file selection box, just hilite a file and use
your keyboard to play notes (/ and * work in there too).
-Readded JACK Driver (Kasper Souren)
-Added RTAUDIO driver, allows for porting to Win32/ASIO and OSX/CoreAudio
-Fixed some big endian compatibility issues. CheeseTracker should work fine
again on big endian machines.
-MacOSX port and build system/build fixes courtesy of Benjamin Reed
-Fixed tons and tons of bugs.
AND NOW PLEASE READ: How fast CheeseTracker reaches version 1.0 depends on
YOU. The focus of this version is STABILITY. Because of this, I need to
receive as many bug reports as I can, both program and build system. If you
find a bug, I'd be enormously grateful if you submit it. Even if it is an
obvious bug to you, chances that other people will find and report the same
bug are much smaller than what you may think. If you dont report a bug that
annoys you, the chances of it reappearing in the next version will allways be
Planned for 1.0.0:
-Rock Solid stability
-A hopefully working Windows port. This depends mainly on the Qt-Win32
project. If you are a good Windows programmer and would like to see
CheeseTracker working in there sooner, please give those guys a hand!
On Monday 27 October 2003 15:08, Benno Senoner wrote:
>Assume I press C2 with velocity 50 pedal up, the C2-pedalup (associated
>to velocity 50) sample sounds.
>Now I press the sustain pedal and press C2 with velocity 100.
>What should the sampler do ? Quickly fade out the C2-pedalup
>(velocity-50) note and trigger the
>C2-pedaldown (velocity 100) note ?
>And of course when you release the pedal all sustained notes will get a
I am a piano player.
I would expect the C2 note to be replaced with the next attack on that note.
If the pedal is pressed, the damper stays up, so the next attack will be the
hammer hitting the strings, and the sounding note is not faded out before.
So I think you should fade out the previous note after or on the attack of the
next one. Maybe even a lot later. There is an adding resonance effect if you
keep hitting the same note with the pedal down, but that is probably the
sympathetic vibrations from the other strings.
If the pedal is not pressed the damper returns to the string as the key is
released to play the next attack. You will get a note off message then
Note that releasing the pedal should only send note-off to those notes that
are sounding, but whose key is not pressed. If you have keys pressed down,
the dampers will be up, regardless of the position of the sustain-pedal. So
these should continue. I have no idea if digital piano's actually do this
correctly, but it is the way a accoustic piano works.
electronic & acoustic musics-- http://www.xs4all.nl/~gml
There's now a mailing list specifically for LADCCA discussion,
ladcca-devel. You can subscribe from here:
Bob Ham <rah(a)bash.sh>
"At some point, keystroke recorders got installed on several machines at
Valve. Our speculation is that these were done via a buffer overflow in
Outlook's preview pane." -- Gabe Newell on the Half-Life 2 source leak