| |||||||||||||
Realtime group scheduling doesn't know JACKRealtime group scheduling doesn't know JACKPosted Dec 20, 2010 23:21 UTC (Mon) by jimparis (subscriber, #38647)In reply to: Realtime group scheduling doesn't know JACK by dlang Parent article: Realtime group scheduling doesn't know JACK
> because the output then gets mixed with the input in the human ear, and the human ear can hear very short delays
The eye can see very short delays too. Certainly moving the mouse or typing on your screen would be a lot less enjoyable if you had 200ms lag in there. And lag alone can't be that big of a problem with audio -- just standing 20 feet away from the speaker will add 20ms on its own.
> when you are in a game and there is a slight delay between hitting the trigger and hearing the sound, it's not really that big a deal, but if the sound from the speakers is delayed from the sound directly from the audio source, it is very jarring.
OK, so it sounds like that concern isn't directly lag, but rather having two sources of audio that are out of sync. And this can often be accounted for by just delaying the faster source slightly to match the delay of the slower (laggier) one. That's how e.g. video games like Rock Band deal with the fact that modern TVs can have quite large lag -- they let you delay the audio so that the audio and video reach the user at the same time.
Can you provide a more specific example setup where you'd see the problem you describe?
(Log in to post comments)
Realtime group scheduling doesn't know JACK Posted Dec 21, 2010 0:05 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
200ms of lag is noticable, but 90ms of lag when typing is probably not
however, 90ms of lag in mixing live audio is very noticable.
the difference is what you are comparing to.
your eyes can detect latency, yes, but they detect it by comparing different visual clues, finger (keyboard) to screen is not all visual.
Realtime group scheduling doesn't know JACK Posted Dec 21, 2010 5:26 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
> Can you provide a more specific example setup where you'd see the problem you describe?
I'm not sure this answers your question exactly, but I used jackd/ardour with live musicians and they can definitely notice if the system is set to higher latencies when you have a mix of live players and earlier recorded tracks. It was easy enough to get the latencies low enough, but it was interesting to me to see them definitely notice the difference.
Realtime group scheduling doesn't know JACK Posted Dec 21, 2010 17:42 UTC (Tue) by drag (subscriber, #31333) [Link]
To get a idea of the scale we are talking about...
The speed of sound in a low humidity environment is going to be something like 350 to 400 meters per second. I've heard that humans can't distinguish 10msec from instantaneous. That would be somebody standing about 4 meters away from you making a sound.
Probably 100msec is acceptable, I figure. From end to end. It'll sound like your standing a ways away in terms of response, but you can compensate.
But if you tune your system to deliver 30msec performance and Linux will randomly have latency spikes past 150 msec every time a disk is accessed then it's worthless to you.
Realtime is about being able to provide deterministic latency.... Linux can't deliver reliable performance without realtime configurations. You can't really tell what latencies you can rely on because the system is not configured to behave in that way. It will be optimized for batch processing and server workloads and in that you can latencies all over the place as long as that will deliver the best performance in the long run.
Realtime group scheduling doesn't know JACK Posted Dec 22, 2010 16:24 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>The speed of sound in a low humidity environment is going to be something like 350 to 400 meters per second. I've heard that humans can't distinguish 10msec from instantaneous. That would be somebody standing about 4 meters away from you making a sound.
Human ear can distinguish about 500 microsecond difference. I.e. a difference in distance of about 20 centimeters. Humans use this for directional hearing.
That's why smallest possible latencies are so important.
Realtime group scheduling doesn't know JACK Posted Dec 22, 2010 19:07 UTC (Wed) by jrigg (subscriber, #30848) [Link]
>Can you provide a more specific example setup where you'd see the problem you describe?
Recording musicians. If there's no way of monitoring what is being played direct from hardware (which is sometimes the case) there needs to be minimal latency between a musician playing something and hearing it back from the recording system, otherwise the musicians can't play in time with each other. If you're paying top money for studio time and session musicians, what might be near enough for a "Guitar Hero" type game isn't good enough. A 20ms delay is enough to cause a problem (musicians don't tend to stand 20 feet from each other in a studio).
There's also the situation when recording or mixing a lot of tracks, possibly with lots of DSP going on, you need certain things to happen within a short deadline to avoid audible dropouts. Large buffers help, but if your system decides to put audio on hold while it does something else it's pretty inconvenient (and in professional audio, inconvenience = cost).
Realtime group scheduling doesn't know JACK Posted Jan 6, 2011 13:18 UTC (Thu) by farnz (guest, #17727) [Link] Practical, real-world example. You are playing electric guitar, accompanying a friend who's singing; you've plugged the guitar and the microphone into the computer, which is recording the raw signals (for later editing), plus acting as a guitar amp, effects box and audio mixer to give you immediate audio feedback in your headphones (basically a first cut of how the final recorded track will sound). You can't delay the (quiet) sound from the guitar strings near you; nor can you delay the loud sound from the friend who's singing. All you can do is minimise the latency in your computer, so that what you hear in your headphones (with effects applied and mixed in) is as close in time to what you're playing to give you a decent experience. Remember, too, that you may well be experimenting ("jamming") - if the singer changes key, the guitarist may want to follow suit (and vice-versa); as that sort of behaviour is unpredictable, you can't try and play ahead to compensate for the latency.
|
|||||||||||||