>Have _you_ ever played a piano?
>
>I respectfully submit that if you had, you'd know that there is a
>delay between pressing a key and the note sounding. I'd have to
>measure to be sure how long it was, but I'd guess its probably more
>than 5msec.
Totally false. The response time for a piano string after being hit by
the hammer is massively under 1msec. If you're referring to the delay
between the start of the key action and when the hammer hits, thats
something else entirely.
There is a delay caused by your distance from the strings: on a full
grand piano, this might be on the order of 2-5msec in some cases. But
thats a quite different result: if you were close-miking the piano,
the microphones wouldn't "suffer" from this effect at all.
> All muscial instruments have this delay.
Totally false. Do you have any physics books that you want to cite for
this ? When you hit a string with something, the oscillations reach
maximum amplitude in an extremely short period of time. Likewise when
you set up a standing wave in the bore of a wind instrument. 5msecs is
a huge overestimate of the time the "attack" phase takes. And do you
want to tell my drumming friends that there is any appreciable delay
in the sound generation after they hit the head of the drum ?
I also have some electronic instruments that have certifiable delays
between the contact switch on the controller and the first sample
being emitted of << 1msec. What are they ? Oh, just good old fashioned
analog synths, where everything works at the speed of electricity on a
wire.
>Also, you are not telling all about the way in which audio signal
>processsing works. While the results need to be heard fast, they are
>most often (eg in the case of reverb, chorus and delay) played after
>the original sound anyway, so some buffering should be possible.
Of *course* there is a delay between the original sound and a delayed
repeat of it (likewise for reverb) - its part of the definition of the
effect, so of course there is buffering.
But there is no inherent delay in: EQ, panning, crossfading,
compression, expansion, limiting, gating ... in other words, the vast
majority of audio processing.
>There is also no reason for there to be a realtime constraint on
>signal processing in the case of sound recording, as a "ghosted"
>version of the processed sound can be used for playback,
Nope. If you work in a studio with, lets say a singer and they are
tracking the recording via headphones, the signal in the headphones
will be the "monitor input" results from the recorder. If there is
more than about 2ms delay between their voice being picked up by the
microphone, and it being fed back to the headphones, they will hear it
as a combination (depending on the person's own internal and ear
acoustics) of flanging and comb filtering.
If the recorder is a computer being used for HDR, it has to meet this
constraint just as the current multitrack tape decks do.
With electronic instruments, this is easier to avoid, but as long as
there are acoustic instruments around with enough volume to rise over
the headphone ear isolation enough, you have no choice but to deal
with this issue.
>When it came to playback after the original recording was done, an
>asynchronous process or thread could be used to read ahead of the
>playback and "render" the raw audio into processed sound buffers which
>would play back just as the "actual" playback off disk happened. This
>would mean that you could provide nice big buffers for your
>third-party plugins, and wouldn't need realtime for them at all.
A correct synopsis of non-real-time audio programming.
>The case of making a instrument (eg a syth) or an effects processor
>for live use (eg a guitar effects unit) is pretty different from this,
>and clearly (in my mind anyway) is a hard realtime project.
Ah, finally, we get down to it: you're not actually talking about the
same problem space that any of the rest of us are.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:10 EST