On Sat, Jun 14, 2003 at 02:12:57AM +1000, Allan Klinbail wrote: Thanks for your reply Allan, I've put some of my controversial opinions in it, please don't feel offended! Me too, unlike some other people I have a 'traditional' setup with mostly hardware synths, effects, mixing desks. Some portions are done by the soft synths, but I do see that more and more of the fine hardware is being virtualised in the software (at the expense of especially the user interface / user interaction).. Perhaps I failed to make my point clear, or even that I forgot to tell the whole context... Some of my points of view: - you want the latency (time between user action, eg. tweaking a real-time control or pressing a key) as low as possible. But don't get trapped in all the marketing stories people want to play My experience is that even with without low latency it is possible to play an instrument, though is more difficult and takes more practice to get the timing right. A latency of >20 ms makes a piano feel kind of sluggish; a latency <10ms gives your the feeling of instant sound. The curch organ is a nice example of an instrument that is difficult to play because of extremely high latency, but good musicians do manage... A nice example of constant delay I keep on using is the propagation velocity of sound waves. At 20 deg, the speed of sound is approximate 330 m/s. Which means that moving the speakers 1 meter further away will cost you 3ms more latency... "Recording engineers" who claim that they can't make a decent mix if the latency is above 10ms might be right with that statement, but I'll be glad to put a bet for a crate of beer on it that they can't do a decent mix with no latency either ;-) - Though the human brain can compensate for latency (constant delay), it can't for jitter (stochastic variable delay). If there is a lot of jitter, it just won't sound right, the groove just isn't there. Every device has latency, every keyboard has latency (time between hitting the key, and event or sound generated), every MIDI synth has latency (time between NOTE ON event coming in and sound generated). The amount of latency depends on the brand/model of the device (eg. my AKAI S3K sampler has lower latency than my Kawai K1 synth etc.). This brings op a rather interesting 3rd point: - In the end, all that counts is that the parts of the composition arrive at the listner's ears at the right time. This implies that you would need to know about the latencies in your system, and compensate for it: If an event is know ahead of time (sequencer playback, but also pre-recorded audio), use that knowledge to ease the system and gain better timing accuracy. This way you can start the longish things before the fast things, with as goal that they are completed at the same time. Now you do know your latencies, but an event comes in to be played 'right now' (eg. a live keyboard player. You have the option to either try to play is best effort, with a certain (hopefully small) latency, or delay everything to mask the individual instrument's latency. In the end the only thing that matters is that it sounds OK and that when the recording is reproduced it sound the same... (already not a trivial question) When comparing a MIDI with a block based digital audio system (eg. Jack) we see an interesting difference: MIDI is event driven, while the audio portion is in fact sampled, with fixed frames per second (numer of frames per second depends on sample rate and block size). Due to the block size processing this inevitely introduces some latency, but what's worse, when viewed from real-time perspective, this latency also has a jitter of up to 1 frame size (which might be quite large!). when a softsynth, running such a frame based audio engine is driven by real-time events like MIDI controls, it has basically 2 options: 1. play the event as soon as possible, ie. next frame, but this introduces a large amount of jitter. 2. determine somehow the timestamp within the frame the event needs to be played, and delay it till that time arrises. For live performance one would typically opt for the first option, unless the sound systems has fairly hight latency (which translates in jitter to the event system!!!!). For other cases the 2nd option would be preferd, since the data is either known ahead of time, or one can introduce a small constant delay. When sending the data from one app to another, this might even make the whole timing worse, unless the last one in the chain still has access to the original timing data, and has the ability to compensate. The moral of my story is that timing hints won't save your ass, but might help you if you either know the event ahead of time (eg. recorded midi sequence), or can introduce a constant delay. A sequencer system does not have a crystal globe to predict the future. Being aware of the artifacts of mixing real-time and frame based systems might help us builing the right tools for great musical compositions... ps: I'm still a very lousy keyboard player, and am heading for some serious beer now. Cheers! -- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol(a)home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available?

I think this is a really sucky direction for synthesis to take, actually. You can turn on and play a MiniMoog without needing anything else around. To have to boot up a lumbering behemoth of a PC just to be able to edit patches, well ... that's just not hardware synthesis. Hardware synthesis means *nothing* else but what is in front of you is needed in order to realize the potential of the hardware. At least, that's what it means to us, anyway ... -- ; Jay Vaughan r&d>>music:technology:synthesizers - www.access-music.de/

Hi Jay, you are right that for good real-time 'play-ability' one wants the latency as low as possible, but I believe that you didn't get my point that the low latency should not be achieved at the expense of high jitter. Running a soft synth with a latency of 10ms would work perfectly OK, though if that same soft synth had a 10ms jitter it would far for easy be audible. Please re-read the original thread. The focus was about providing timestamp information from sequencer to soft synths to be able to achieve sample accurate triggering of the events. And also touches some aspects of jitter vs latency: adding additional (a small bit of) delay might improve the real-time performance/play-ability of your synth if you can lower the jitter (at the expense of latency). On Mon, Jun 16, 2003 at 06:59:40AM +0200, Jay Vaughan wrote: Especially during a live performance the low jitter is important. Musicians are used to perform with small latency... think about the time it takes before the sound emitted from a speaker arrives at the ear. But if that programmer receives events from a MIDI port, and has to work with block/frame based sample audio, things are not that easy anymore. It is not the latency that wil be your worry but rather the jitter. If you are talking about extremely high latency like 200ms or more I agree with you. But if recording engineers are whining that a latency of 10ms is too high for them to make a mix they better find a new job... Remember the velocity of sound waves in air; 10ms is equivalent of your speakers at 3m distance, not an uncommon thing for a pair of mid-fields. I feel amost sorry <grin> for those musicians that are playing electric guitars are are a few meters away from their amps. Not to mention those realy poor sound engineers doing the live mix for the FOH (front of house) PA system of an open air concert (distance from mixing desk to FOH for example 50m; causing a whopping 150ms of latency). Despite all of this, those magicians do manage to make great sounding music without any concerns about the latency. please remember after me: J I T T E R I'm just approaching the issue from a different angle, and taking other aspects in consideration. No need to value any of our opions though. I'd be glad to learn from my misunderstandings, that's life for an EE. I noticed that you are working for Access, and have a vague clue where the misunderstanding might come from. I presume the Virus DSPs are running the algoritms blockless, ie. rendering one sample and streaming it to the DACs. This means that the delay from event reception till sound generation is constant and virtually without jitter. When compared to the Linux sound system this would be a luxery situation since the data is always send to the DACs in small or larger blocks. This block size is reponsible for the latency, but also might cause jitter if you want to get the signal out the box as soon as possible. Frank. -- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol(a)home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available?