1 Jan
2014
1 Jan
'14
2:21 p.m.
Happy New Year all,
I was curious, if doubling the sample rate is a
practical way to reduce latency for live effects
processing. I would think it would reduce latency by half.
If one wanted to avoid the tradeoff of handling twice the
usual amount of audio data, I was curious if ALSA sample
rate conversion, or some other clever hack could be used to
get low latency advantage of the high sample rate, while
actually dealing with 48k streams through JACK.
best wishes,
Joel
--
Joel Roth
1 Jan
1 Jan
2:56 p.m.
On Wed, Jan 1, 2014 at 1:21 PM, Joel Roth <joelz(a)pobox.com> wrote:
I was curious, if doubling the sample rate is a
practical way to reduce latency for live effects
processing. I would think it would reduce latency by half.
It would: you mention "practical", i'm not sure I'd call it that.
If one wanted to avoid the tradeoff of handling twice
the
usual amount of audio data,
CPU load will go up, since there is 2x more of data to process,
which also means every plugin / host has 2x more work to do.
Adds up quickly if you're doing things like convolution reverbs
or other CPU intense processing..
I was curious if ALSA sample
rate conversion, or some other clever hack could be
used to
get low latency advantage of the high sample rate, while
actually dealing with 48k streams through JACK.
Theoretically possible I suppose, it seems like an awful lot of
effort to get a few less ms latency..
Latency below ~3ms isn't percievable at all IMO: most will agree.
Why not run jack at 64 frames, 2 buffers? That'll achieve approx
3ms (on 44.1kHz and 48kHz).. which is fine for the purpose?
Perhaps I'm missing something, are you doing mulitple passes
trough the sound-card that you're adding its latency two or more times?
Cheers, -Harry
6:18 p.m.
On Wed, 2014-01-01 at 13:56 +0000, Harry van Haaren wrote:
On Wed, Jan 1, 2014 at 1:21 PM, Joel Roth
<joelz(a)pobox.com> wrote:
I was curious, if doubling the sample rate is a
practical way to reduce latency for live effects
processing. I would think it would reduce latency by half.
It would: you mention "practical", i'm not sure I'd call it that.
If one wanted to avoid the tradeoff of handling twice the
usual amount of audio data,
CPU load will go up, since there is 2x more of data to process,
which also means every plugin / host has 2x more work to do.
Adds up quickly if you're doing things like convolution reverbs
or other CPU intense processing..
I was curious if ALSA sample
rate conversion, or some other clever hack could be used to
get low latency advantage of the high sample rate, while
actually dealing with 48k streams through JACK.
Theoretically possible I suppose, it seems like an awful lot of
effort to get a few less ms latency..
Latency below ~3ms isn't percievable at all IMO: most will agree.
Why not run jack at 64 frames, 2 buffers? That'll achieve approx
3ms (on 44.1kHz and 48kHz).. which is fine for the purpose?
Perhaps I'm missing something, are you doing mulitple passes
trough the sound-card that you're adding its latency two or more
times?
Filters of audio devices usually are optimized for 48 KHz usage, but on
this list there often where discussions about this issue and IIRC 96 KHz
are indeed used to lower latency for live usage.
I recommend to search the archive.
Happy New Year!
Ralf
9:19 p.m.
On Wed, 1 Jan 2014, Harry van Haaren wrote:
Latency below ~3ms isn't percievable at all IMO:
most will agree.
Why not run jack at 64 frames, 2 buffers? That'll achieve approx
3ms (on 44.1kHz and 48kHz).. which is fine for the purpose?
Unless it is an internal audio IF... My experience with HDA stuff is, the
minimum is 128 frames before Jack will even start. Though 64 frames may
work with 3 buffers. Still quite good though. Usable with guitarix for
example.
--
Len Ovens
www.ovenwerks.net
2 Jan
2 Jan
6:25 a.m.
Harry van Haaren wrote:
On Wed, Jan 1, 2014 at 1:21 PM, Joel Roth
<joelz(a)pobox.com> wrote:
I was curious, if doubling the sample rate is a
practical way to reduce latency for live effects
processing. I would think it would reduce latency by half.
It would: you mention "practical", i'm not sure I'd call it that.
If one wanted to avoid the tradeoff of handling
twice the
usual amount of audio data,
CPU load will go up, since there is 2x more of data to process,
which also means every plugin / host has 2x more work to do.
Adds up quickly if you're doing things like convolution reverbs
or other CPU intense processing..
I was curious if ALSA sample
rate conversion, or some other clever hack could
be used to
get low latency advantage of the high sample rate, while
actually dealing with 48k streams through JACK.
Theoretically possible I suppose, it seems like an awful lot of
effort to get a few less ms latency..
Latency below ~3ms isn't percievable at all IMO: most will agree.
Why not run jack at 64 frames, 2 buffers? That'll achieve approx
3ms (on 44.1kHz and 48kHz).. which is fine for the purpose? Perhaps I'm missing something, are you doing
mulitple passes
trough the sound-card that you're adding its latency two or more times?
For a live submix, the routing I want to use is exemplified by:
system:capture_5 --> Nama:sax_in_1 --( ecasound )--> Nama:sax_out_1
Nama:sax_out_1 --( ecasound )--> system:playback_11
If I understand correctly, the latency not due to Ecasound
in this graph is the soundcard roundtrip plus the number of
hops which contribute (frames*buffers/sample-rate) latency
per.
I'm adding one more hop, so that would be 3ms
at 64/2, 4ms at 64/3, and 5.3ms at 128/2.
Regards,
Joel
Cheers, -Harry
--
Joel Roth
12:50 p.m.
Wait a minute. This discussion is making my head spin! How is there any way at all that
increasing the sampling rate, and changing nothing else, will improve the lowest reliable
latency of a system?
Lowest latency in my experience is a function of the longest time (in microseconds or
milliseconds) that you can expect your system to be unavailable for audio processing due
to other kernel work such as disk IO, plus whatever per-cycle setup overhead you have in
your application, plus data processing time. If that is, say, 5ms at 48 kHz, the kernel
latency part (which generally dominates) will be 5ms at 96 kHz (or 32 kHz, or...) unless
you reconfigure your system to improve kernel behavior, or improve your app's
performance.
Or are you just talking about the boundary case where kernel-dependent latency is very low
and you are limited by the smallest buffer size that the ALSA driver supports? In that
case I guess this would work. But you are more than doubling the amount of work your
system is doing, and if you are at the buffer size lower limit already, is it really an
audible improvement?
Am I missing something?
Thanks,
Bill Gribble
On Jan 2, 2014, at 0:25, Joel Roth
<joelz(a)pobox.com> wrote:
Harry van Haaren wrote:
On Wed,
Jan 1, 2014 at 1:21 PM, Joel Roth <joelz(a)pobox.com> wrote:
I was curious, if doubling the sample rate is a
practical way to reduce latency for live effects
processing. I would think it would reduce latency by half.
It would: you mention "practical", i'm not sure I'd call it that.
If one wanted to avoid the tradeoff of handling
twice the
usual amount of audio data,
CPU load will go up, since there is 2x more of data to process,
which also means every plugin / host has 2x more work to do.
Adds up quickly if you're doing things like convolution reverbs
or other CPU intense processing..
I was curious if ALSA sample
rate conversion, or some other clever hack could
be used to
get low latency advantage of the high sample rate, while
actually dealing with 48k streams through JACK.
Theoretically possible I suppose,
it seems like an awful lot of
effort to get a few less ms latency..
Latency below ~3ms isn't percievable at all IMO: most will agree.
Why not run jack at 64 frames, 2 buffers? That'll achieve approx
3ms (on 44.1kHz and 48kHz).. which is fine for the purpose? Perhaps I'm missing something, are you doing
mulitple passes
trough the sound-card that you're adding its latency two or more times?
For a live submix, the routing I want to use is exemplified by:
system:capture_5 --> Nama:sax_in_1 --( ecasound )--> Nama:sax_out_1
Nama:sax_out_1 --( ecasound )--> system:playback_11
If I understand correctly, the latency not due to Ecasound
in this graph is the soundcard roundtrip plus the number of
hops which contribute (frames*buffers/sample-rate) latency
per.
I'm adding one more hop, so that would be 3ms
at 64/2, 4ms at 64/3, and 5.3ms at 128/2.
Regards,
Joel
Cheers, -Harry
--
Joel Roth
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
1:27 p.m.
On Thu, Jan 2, 2014 at 11:49 AM, Bill Gribble <grib(a)billgribble.com> wrote:
How is there any way at all that increasing the
sampling rate, and
changing nothing else, will improve the lowest reliable latency
of a system?
The question here isn't really about lowest reliable latency, but reducing
latency by changing samplerate. Reliable latency is a totally different
question which indeed involves system tuning, RT kernels, IRQ threading &
priority etc.
You'll know this but for completeness, a simple example:
Keeping the "number of buffers" and "frames per buffer" constant,
increasing the samplerate will reduce latency purely because the number of
sames represents less time at the higher sample rate.
64 x 2 @ 48kHz = 2.67msec
64 x 2 @ 96kHz = 1.33msec
=> Doubling the samplerate halves the latency
Cheers, -Harry
2:31 p.m.
On Jan 2, 2014, at 7:26, Harry van Haaren
<harryhaaren(a)gmail.com> wrote:
64 x 2 @ 48kHz = 2.67msec
64 x 2 @ 96kHz = 1.33msec
=> Doubling the samplerate halves the latency
Sure, that math is correct, but this is not a really interesting observation if (as I
interpret the OP to be) you are trying to wring the lowest-latency performance out of a
real system...
If, in the case you describe, you are at "best possible latency" at 48 kHz,
simply increasing the sample rate is almost guaranteed to put you in XRUN hell. You are
asking the system to respond in half the time you had previously determined was its best
possible effort.
Thanks,
Bill Gribble
3:06 p.m.
On Thu, Jan 2, 2014 at 6:49 AM, Bill Gribble <grib(a)billgribble.com> wrote:
Wait a minute. This discussion is making my head
spin! How is there any
way at all that increasing the sampling rate, and changing nothing else,
will improve the lowest reliable latency of a system?
Fons' point, which I believe started this, was that the latency caused by
A/D and D/A converters is reduced (or can be reduced) when using a higher
SR. Nothing more. When you're already using very small buffer sizes at the
CPU level, reducing these additional delays in the analog conversion
process can be signficant.
There is an additional point that some devices cannot be configured to use
a buffer size below a given value, and so even if you system could handle
the lower latency setting, the only way to get there is to double the SR.
1 Jan
1 Jan
8:48 p.m.
On Wed, Jan 01, 2014 at 03:21:29AM -1000, Joel Roth wrote:
I was curious, if doubling the sample rate is a
practical way to reduce latency for live effects
processing. I would think it would reduce latency by half.
At least by half, and if the antialiasing filters in the AD/DA
converters are designed for it, much better. When using small
period sizes (32 or less), the delay in these filters (which
are usually linear phase) will be the largest contribution to
latency.
This delay is roughy inversely proportional to the transition
band of the filter. If you don't use the full bandwidth that
96 kHz offers (up to 48 kHz) it could be much less than half
the value at 48 kHz. This is why 'digital snakes' connecting
stage and FOH mixer use 96 kHz.
If one wanted to avoid the tradeoff of handling twice
the
usual amount of audio data, I was curious if ALSA sample
rate conversion, or some other clever hack could be used to
get low latency advantage of the high sample rate, while
actually dealing with 48k streams through JACK.
That won't work. Resampling requires the same type of filters,
when you resample to/from 48 kHz you'll get the same delay as
an AD/DA operating at that frequency.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
10:33 p.m.
On Wed, Jan 1, 2014 at 7:48 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
At least by half, and if the antialiasing filters in
the AD/DA
converters are designed for it, much better. When using small
period sizes (32 or less), the delay in these filters (which
are usually linear phase) will be the largest contribution to
latency.
This delay is roughy inversely proportional to the transition
band of the filter. If you don't use the full bandwidth that
96 kHz offers (up to 48 kHz) it could be much less than half
the value at 48 kHz. This is why 'digital snakes' connecting
stage and FOH mixer use 96 kHz.
Interesting, I didn't know this. I will re-check my setup with jack_iodelay
and see what values actually turn up.
3 Jan
3 Jan
2:12 a.m.
Fons Adriaensen wrote:
On Wed, Jan 01, 2014 at 03:21:29AM -1000, Joel Roth
wrote:
I was curious, if doubling the sample rate is a
practical way to reduce latency for live effects
processing. I would think it would reduce latency by half.
At least by half, and if the antialiasing filters in the AD/DA
converters are designed for it, much better. When using small
period sizes (32 or less), the delay in these filters (which
are usually linear phase) will be the largest contribution to
latency. This delay is roughy inversely proportional to the
transition
band of the filter. If you don't use the full bandwidth that
96 kHz offers (up to 48 kHz) it could be much less than half
the value at 48 kHz. This is why 'digital snakes' connecting
stage and FOH mixer use 96 kHz.
Thanks for speaking up, Fons. I learn something new in
everything you post.
--
Joel Roth
4051
days inactive
4053
days old
linux-audio-user@lists.linuxaudio.org
11 comments
7 participants
participants (7)
-
Bill Gribble -
Fons Adriaensen -
Harry van Haaren -
Joel Roth -
Len Ovens -
Paul Davis -
Ralf Mardorf