19 Feb
2013
19 Feb
'13
8:25 p.m.
From: jonetsu(a)teksavvy.com
If a better response time from the kernel is something that's Good, why
isn't lowlatency kernels a default in Linux distros (well, at least in
Linux Mint and Fedora) If it is So Good, what are the arguments for not
having a lowlatency kernel by default ? Any drawbacks ? I presume the
Audio-oriented Linux distros do have lowlatency kernels by default, do
they ?
The Fedora Musicians Guide has a good topic on Real-Time and Low-Latency:
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Mus…
My understanding:
* A Real-Time kernel will give you more consistent, reliable latency.
- But not necessarily lower latency
* Useful, proven, RT features migrate into the main kernel.
- So use the RT patches to test and prove them.
* Current main kernels give reasonable performance for most musicians.
- Your mileage may vary, if you get some annoying x-runs use the RT patch.
- Sound travels ~1 foot per millisecond, 8 feet from the speaker =
8ms latency
-- Jeff
19 Feb
19 Feb
10:16 p.m.
New subject: Basic question about use of a lowlatency kernel
On Tue, February 19, 2013 11:25 am, Jeff Sandys wrote:
- Sound travels ~1 foot per millisecond, 8 feet
from the speaker =
8ms latency
latency as listed by qjackctl (for example) is one way from the card's
buffer to jack. Double that by the time it gets back to the card. Cards
typically add 1ms each way. So with 64f/p at 48khz the one way latency is
2.67 + 1ms from the analog input. This is already pretty close to that
8ms... and I haven't done anything with the audio yet. Add eq, tube
emulation, box emulation, reverb, etc. and they all add more delay to the
signal.
This delay is more of a problem for live computer use than recording where
monitoring can happen outside the computer. Just to compare: if I put a
long enough cord on my bass so I can get 25 to 30 ft from my amp (to
adjust sound on the mixer) my timing is already having problems. This
would be about 50ft of sound travel, 25ft before I hear what the rest of
the band is doing plus 25 feet before I hear my own instrument. I can
notice the delay before I get to that 25feet by the way.
Now if I am just listening, I can be 100 feet away and it still sounds
fine... It is the interaction with that sound that shows up the latency,
the time from when I do something to when I hear it. A good reason to use
in ear monitoring on a large stage.
--
Len Ovens
www.OvenWerks.net
10:52 p.m.
New subject: Basic question about use of a lowlatency kernel
On Tue, 19 Feb 2013 22:16:24 +0100, Len Ovens <len(a)ovenwerks.net> wrote:
On Tue, February 19, 2013 11:25 am, Jeff Sandys wrote:
Fixed latency seldom is a serious issue and 10 meters for me completely
doesn't matter. When QjackCtl displays a latency of 10.7 msec and I don't
get jitter, than this only could be an issue, if I play a nice groove with
a drum sampler, then I have to feel, perhaps to sing, what I'm playing and
to ignore a little bit what I hear. For those who anyway hard quantise
even this shouldn't matter. For me issues start with minimal jitter or a
fixed latency > 10.7 msec. When talking about jitter, I'm talking about
MIDI jitter, audio jitter just will make the sound muddy, but aren't an
issue regarding to timing.
If I would be rich, I would use analog gear, that btw. has latency too. I
guess looping in effects could be a serious issue for digital recording
with higher latencies. Until now I only loop in reverb and I simply reduce
the reverb's delay by the latency time.
YMMV!
- Sound travels ~1 foot per millisecond, 8
feet from the speaker =
8ms latency
latency as listed by qjackctl (for example) is one way from the card's
buffer to jack. Double that by the time it gets back to the card. Cards
typically add 1ms each way. So with 64f/p at 48khz the one way latency is
2.67 + 1ms from the analog input. This is already pretty close to that
8ms... and I haven't done anything with the audio yet. Add eq, tube
emulation, box emulation, reverb, etc. and they all add more delay to the
signal.
This delay is more of a problem for live computer use than recording
where
monitoring can happen outside the computer. Just to compare: if I put a
long enough cord on my bass so I can get 25 to 30 ft from my amp (to
adjust sound on the mixer) my timing is already having problems. This
would be about 50ft of sound travel, 25ft before I hear what the rest of
the band is doing plus 25 feet before I hear my own instrument. I can
notice the delay before I get to that 25feet by the way.
Now if I am just listening, I can be 100 feet away and it still sounds
fine... It is the interaction with that sound that shows up the latency,
the time from when I do something to when I hear it. A good reason to use
in ear monitoring on a large stage. 
20 Feb
20 Feb
8:37 a.m.
New subject: Basic question about use of a lowlatency kernel
[Len Ovens]
On Tue, February 19, 2013 11:25 am, Jeff Sandys wrote:
If they're well-engineered, latency from the digital effects listed
will amount to well under half a millisecond.
Tim
- Sound travels ~1 foot per millisecond, 8
feet from the speaker =
8ms latency
latency as listed by qjackctl (for example) is one way from the card's
buffer to jack. Double that by the time it gets back to the card. Cards
typically add 1ms each way. So with 64f/p at 48khz the one way latency is
2.67 + 1ms from the analog input. This is already pretty close to that
8ms... and I haven't done anything with the audio yet. Add eq, tube
emulation, box emulation, reverb, etc. and they all add more delay to the
signal.
9:01 a.m.
New subject: Basic question about use of a lowlatency kernel
On Tue, February 19, 2013 11:39 pm, Tim Goetze wrote:
[Len Ovens]
While I don't doubt the calculations could be done in that time, I assumed
they would still have to use the same size buffering as jack, so even if
it was all done internal to one effect there would still be at least
2.67ms in the example above. 2.6ms each if they each hit jack in between.
TBH, I have used my netbook as a guitar effect with 128f/p and no
noticable delay.
--
Len Ovens
www.OvenWerks.net
On Tue, February 19, 2013 11:25 am, Jeff Sandys
wrote:
If they're well-engineered, latency from the digital effects listed
will amount to well under half a millisecond. - Sound travels ~1 foot per millisecond, 8
feet from the speaker =
8ms latency
latency as listed by qjackctl (for example) is one way from the card's
buffer to jack. Double that by the time it gets back to the card. Cards
typically add 1ms each way. So with 64f/p at 48khz the one way latency is
2.67 + 1ms from the analog input. This is already pretty close to that
8ms... and I haven't done anything with the audio yet. Add eq, tube
emulation, box emulation, reverb, etc. and they all add more delay to the
signal.
10:51 a.m.
New subject: Basic question about use of a lowlatency kernel
[Len Ovens]
While I don't doubt the calculations could be done
in that time, I assumed
they would still have to use the same size buffering as jack, so even if
it was all done internal to one effect there would still be at least
2.67ms in the example above. 2.6ms each if they each hit jack in between.
TBH, I have used my netbook as a guitar effect with 128f/p and no
noticable delay.
If you're not doing anything funky (and you'd have to go out of your
way to), multiple jack clients can indeed process the signal without
adding any latency. Marvellous, isn't it?
Tim
11:26 a.m.
New subject: Basic question about use of a lowlatency kernel
On Wed, Feb 20, 2013 at 6:52 PM, Tim Goetze <tim(a)quitte.de> wrote:
If you're not doing anything funky (and you'd
have to go out of your
way to)
My understanding is that the latency measure displayed by JACK is for one
cycle of the entire JACK graph (or something like that). That means apps in
a standard linear signal chain won't add extra latency. It also means you
don't have to be that funky to add extra latency - just put a loop anywhere
in your signal chain (eg. a send from Ardour to an external jack app and
back into Ardour). The audio won't be processed by the client at the loop
point until the next execution cycle, effectively adding a full cycle of
latency at that point in the signal chain.
At least, that's how I think it was patiently explained to me a while back.
11:38 a.m.
New subject: Basic question about use of a lowlatency kernel
[michael noble]
On Wed, Feb 20, 2013 at 6:52 PM, Tim Goetze
<tim(a)quitte.de> wrote:
It's true, and I consider a processing graph containing a loop funky.
It seems our funkiness scales are calibrated to different references.
:)
Tim
If you're not doing anything funky (and
you'd have to go out of your
way to)
My understanding is that the latency measure displayed by JACK is for one
cycle of the entire JACK graph (or something like that). That means apps in
a standard linear signal chain won't add extra latency. It also means you
don't have to be that funky to add extra latency - just put a loop anywhere
in your signal chain (eg. a send from Ardour to an external jack app and
back into Ardour). The audio won't be processed by the client at the loop
point until the next execution cycle, effectively adding a full cycle of
latency at that point in the signal chain.
At least, that's how I think it was patiently explained to me a while back.
12:49 p.m.
New subject: Basic question about use of a lowlatency kernel
On Wed, Feb 20, 2013 at 7:40 PM, Tim Goetze <tim(a)quitte.de> wrote:
It's true, and I consider a processing graph
containing a loop funky.
It seems our funkiness scales are calibrated to different references.
I often need re-calibration, but we're not talking George Clinton funky,
that's for sure...
9:34 a.m.
New subject: Basic question about use of a lowlatency kernel
On 02/19/2013 09:25 AM, Jeff Sandys wrote:
So what's the latency for headphones?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://clanjones.org/david/
http://dancing-treefrog.deviantart.com/
From:
jonetsu(a)teksavvy.com
If a better response time from the kernel is something that's Good, why
isn't lowlatency kernels a default in Linux distros (well, at least in
Linux Mint and Fedora) If it is So Good, what are the arguments for not
having a lowlatency kernel by default ? Any drawbacks ? I presume the
Audio-oriented Linux distros do have lowlatency kernels by default, do
they ?
The Fedora Musicians Guide has a good topic on Real-Time and Low-Latency:
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Mus…
My understanding:
* A Real-Time kernel will give you more consistent, reliable latency.
- But not necessarily lower latency
* Useful, proven, RT features migrate into the main kernel.
- So use the RT patches to test and prove them.
* Current main kernels give reasonable performance for most musicians.
- Your mileage may vary, if you get some annoying x-runs use the RT patch.
- Sound travels ~1 foot per millisecond, 8 feet from the speaker =
8ms latency
4296
days inactive
4297
days old
linux-audio-user@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
david -
Jeff Sandys -
Len Ovens -
michael noble -
Ralf Mardorf -
Tim Goetze