12 Dec
2010
12 Dec
'10
1:03 p.m.
I've been looking around for any tests made comparing the different
kernels, -rt, generic, or any other type of realtime enchanced kernel.
I haven't found any test results yet, at least none audio related. I did
find some testing tools at rt.wiki.kernel.org, but don't know if and how
they could be made relevant to audio low latency testing.
I suppose the most interesting results would come from testing different
kernels with jack/alsa and jack/ffado.
Has anyone done such tests?
--
ailo
12 Dec
12 Dec
1:35 p.m.
ailo wrote:
I've been looking around for any tests made
comparing the different
kernels, -rt, generic, or any other type of realtime enchanced kernel.
I haven't found any test results yet, at least none audio related. I did
find some testing tools at rt.wiki.kernel.org, but don't know if and how
they could be made relevant to audio low latency testing.
I suppose the most interesting results would come from testing different
kernels with jack/alsa and jack/ffado.
Has anyone done such tests?
There is jack_delay from fons, which can measure the effective overall
latency of your soundcard/drivers/jack/whatever. Plus there is a
"latency.pd" patch that does the same (but with less precision) and
which also features a nice "continuity" measurement, detecting cliks and
dropouts.
best, P
3:58 p.m.
On 12/12/2010 01:34 PM, Peter Plessas wrote:
ailo wrote:
I've must have seen "latency.pd" at some point, but forgotten about it.
Since I use pd almost exclusively I will find it most useful.
I will also have a look at jack_delay.
Thanks.
--
ailo
I've been looking around for any tests made
comparing the different
kernels, -rt, generic, or any other type of realtime enchanced kernel.
I haven't found any test results yet, at least none audio related. I did
find some testing tools at rt.wiki.kernel.org, but don't know if and how
they could be made relevant to audio low latency testing.
I suppose the most interesting results would come from testing different
kernels with jack/alsa and jack/ffado.
Has anyone done such tests?
There is jack_delay from fons, which can measure the effective overall
latency of your soundcard/drivers/jack/whatever. Plus there is a
"latency.pd" patch that does the same (but with less precision) and
which also features a nice "continuity" measurement, detecting cliks and
dropouts.
best, P
1:41 p.m.
On 12/12/2010 01:03 PM, ailo wrote:
I've been looking around for any tests made
comparing the different
kernels, -rt, generic, or any other type of realtime enchanced kernel.
I haven't found any test results yet, at least none audio related. I did
find some testing tools at rt.wiki.kernel.org, but don't know if and how
they could be made relevant to audio low latency testing.
I suppose the most interesting results would come from testing different
kernels with jack/alsa and jack/ffado.
Has anyone done such tests?
It is not trivial to perform such tests and AFAIK there's no benchmark
suite to automate the process.
There are a few tools to test JACK's realtime performance:
- the ardour-source includes `tools/jacktest.c` checks for the max DSP
load at which an x-run occurs.
- http://wiki.linuxaudio.org/wiki/jack_latency_tests
git://rg42.org/latentor is a tool to automate measuring round-trip
audio latency iterating all JACKd -n/-p/-S parameters
However latentor is a pretty recent development and does not yet
report x-runs. We watch qjackctl's icon for now.
AFAICT there's no recipe. It's a matter of knowing some internals about
RT-linux to come up with a proper kernel .config and doing real-life
tests. I think it is impossible to assign a number "suitability for
pro-audio" to a kernel.
For testing performance of the 64studio RT kernel: I do run a couple of
heavy-sessions (e.g. 16 jconvolvers in a 16 track ardour session + jamin
which procudes quite some DSP, system and IO load). If there's no x-run
at 32fpp*2p/48kHz after 24 h while I to surf the web and read email and
compile another kernel in the meantime I bless the build OK :) There's a
few additional things: wifi, suspend/resume, freq scaling, etc on the
checklist, too.
2c,
robin
2:09 p.m.
Thanks Robin for your massively useful tips there on how to (stress) test
JACK - I think what you just said, in an edited form, should be included on
the JACK FAQ page please Paul!
On Sun, Dec 12, 2010 at 12:41 PM, Robin Gareus <robin(a)gareus.org> wrote:
On 12/12/2010 01:03 PM, ailo wrote:
I've been looking around for any tests made
comparing the different
kernels, -rt, generic, or any other type of realtime enchanced kernel.
I haven't found any test results yet, at least none audio related. I did
find some testing tools at rt.wiki.kernel.org, but don't know if and how
they could be made relevant to audio low latency testing.
I suppose the most interesting results would come from testing different
kernels with jack/alsa and jack/ffado.
Has anyone done such tests?
It is not trivial to perform such tests and AFAIK there's no benchmark
suite to automate the process.
There are a few tools to test JACK's realtime performance:
- the ardour-source includes `tools/jacktest.c` checks for the max DSP
load at which an x-run occurs.
- http://wiki.linuxaudio.org/wiki/jack_latency_tests
git://rg42.org/latentor is a tool to automate measuring round-trip
audio latency iterating all JACKd -n/-p/-S parameters
However latentor is a pretty recent development and does not yet
report x-runs. We watch qjackctl's icon for now.
AFAICT there's no recipe. It's a matter of knowing some internals about
RT-linux to come up with a proper kernel .config and doing real-life
tests. I think it is impossible to assign a number "suitability for
pro-audio" to a kernel.
For testing performance of the 64studio RT kernel: I do run a couple of
heavy-sessions (e.g. 16 jconvolvers in a 16 track ardour session + jamin
which procudes quite some DSP, system and IO load). If there's no x-run
at 32fpp*2p/48kHz after 24 h while I to surf the web and read email and
compile another kernel in the meantime I bless the build OK :) There's a
few additional things: wifi, suspend/resume, freq scaling, etc on the
checklist, too.
2c,
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3:51 p.m.
On 12/12/2010 01:41 PM, Robin Gareus wrote:
On 12/12/2010 01:03 PM, ailo wrote:
Thanks for your excellent info.
I will need to have a closer look on specific details to get a better
understanding of the problem with doing this kind of testing.
Kernel .config is not my language yet, for instance.
From a practical point of view for someone as ignorant about the
technical details as myself, I suppose I'm just trying to get a general
idea of what you get from different kernels.
So, I was making outlines on how to do these two things:
1. a test/script for making tests on a single machine to compare
performance on different kernels.
2. results summed up in a table that gives you a general idea of what
you get with different kernels.
There could perhaps be a number of different tables for different
processors, assuming that the processor is the main important factor
that decides the actual latency you get with a kernel.
These tests could then be published in a wiki, if deemed worthy.
- Why such a table should be made, and for who?:
Some practical uses that may require a rt kernel:
* live audio processing (requires low latency)
* monitoring (requires low latency)
* using firewire devices (As far as I understand ffado works best with
-rt kernels)
Possible/impossible?
--
ailo
I've been looking around for any tests made
comparing the different
kernels, -rt, generic, or any other type of realtime enchanced kernel.
I haven't found any test results yet, at least none audio related. I did
find some testing tools at rt.wiki.kernel.org, but don't know if and how
they could be made relevant to audio low latency testing.
I suppose the most interesting results would come from testing different
kernels with jack/alsa and jack/ffado.
Has anyone done such tests?
It is not trivial to perform such tests and AFAIK there's no benchmark
suite to automate the process.
There are a few tools to test JACK's realtime performance:
- the ardour-source includes `tools/jacktest.c` checks for the max DSP
load at which an x-run occurs.
- http://wiki.linuxaudio.org/wiki/jack_latency_tests
git://rg42.org/latentor is a tool to automate measuring round-trip
audio latency iterating all JACKd -n/-p/-S parameters
However latentor is a pretty recent development and does not yet
report x-runs. We watch qjackctl's icon for now.
AFAICT there's no recipe. It's a matter of knowing some internals about
RT-linux to come up with a proper kernel .config and doing real-life
tests. I think it is impossible to assign a number "suitability for
pro-audio" to a kernel.
For testing performance of the 64studio RT kernel: I do run a couple of
heavy-sessions (e.g. 16 jconvolvers in a 16 track ardour session + jamin
which procudes quite some DSP, system and IO load). If there's no x-run
at 32fpp*2p/48kHz after 24 h while I to surf the web and read email and
compile another kernel in the meantime I bless the build OK :) There's a
few additional things: wifi, suspend/resume, freq scaling, etc on the
checklist, too.
2c,
robin
5:17 p.m.
Hi Ailo,
Well this will get a bit long.. I hope you don't mind.
On 12/12/2010 03:51 PM, ailo wrote:
On 12/12/2010 01:41 PM, Robin Gareus wrote:
for 'latentor', Luis and me are pondering to move away from the wiki and
add some phone-home support to collect data from various systems.
But it's not high-priority and we question the use-fullness of such
information, anyway.
On 12/12/2010 01:03 PM, ailo wrote:
Thanks for your excellent info.
I will need to have a closer look on specific details to get a better
understanding of the problem with doing this kind of testing.
Kernel .config is not my language yet, for instance.
From a practical point of view for someone as ignorant about the
technical details as myself, I suppose I'm just trying to get a general
idea of what you get from different kernels.
So, I was making outlines on how to do these two things:
1. a test/script for making tests on a single machine to compare
performance on different kernels.
2. results summed up in a table that gives you a general idea of what
you get with different kernels.
There could perhaps be a number of different tables for different
processors, assuming that the processor is the main important factor
that decides the actual latency you get with a kernel.
These tests could then be published in a wiki, if deemed worthy. I've been looking around for any tests made
comparing the different
kernels, -rt, generic, or any other type of realtime enchanced kernel.
I haven't found any test results yet, at least none audio related. I did
find some testing tools at rt.wiki.kernel.org, but don't know if and how
they could be made relevant to audio low latency testing.
I suppose the most interesting results would come from testing different
kernels with jack/alsa and jack/ffado.
Has anyone done such tests?
It is not trivial to perform such tests and AFAIK there's no benchmark
suite to automate the process.
There are a few tools to test JACK's realtime performance:
- the ardour-source includes `tools/jacktest.c` checks for the max DSP
load at which an x-run occurs.
- http://wiki.linuxaudio.org/wiki/jack_latency_tests
git://rg42.org/latentor is a tool to automate measuring round-trip
audio latency iterating all JACKd -n/-p/-S parameters
However latentor is a pretty recent development and does not yet
report x-runs. We watch qjackctl's icon for now.
AFAICT there's no recipe. It's a matter of knowing some internals about
RT-linux to come up with a proper kernel .config and doing real-life
tests. I think it is impossible to assign a number "suitability for
pro-audio" to a kernel.
For testing performance of the 64studio RT kernel: I do run a couple of
heavy-sessions (e.g. 16 jconvolvers in a 16 track ardour session + jamin
which procudes quite some DSP, system and IO load). If there's no x-run
at 32fpp*2p/48kHz after 24 h while I to surf the web and read email and
compile another kernel in the meantime I bless the build OK :) There's a
few additional things: wifi, suspend/resume, freq scaling, etc on the
checklist, too.
2c,
robin - Why such a table should be made, and for who?:
Some practical uses that may require a rt kernel:
* live audio processing (requires low latency)
* monitoring (requires low latency)
* using firewire devices (As far as I understand ffado works best with
-rt kernels)
Possible/impossible?
short-answer: "impossible" - meaning: theoretically possible but not
feasible.
long-answer and brainstorm:
The question is whether it is worth the time to make it, and what can be
learned from the information.
End-users won't learn much from those statistics. Unless you have
exactly the same hardware, it is close to impossible to draw
conclusions. One would need to
a) isolate the correlating factors and there are certainly much more
than just the kernel-revision, flavor, CPU-speed and audio-interface.
b) find values that can be measured reliably.
eg. what would you learn from information such as:
With kernel A on system B using sound-card C and jack-settings D
one can run for >=X seconds without an x-run.
where D is chosen to maximize X while f.i. minimizing latency.
Besides there is no common goal: some end-users require huge I/O (read
128 audio tracks from disk). Others only need one channel but low
latency, yet others only CPU power for effect-processing.
As for making something that is useful for developers: compare different
versions, do regression tests on the same system. It will take huge
effort to pull it off. Maybe the Phoronix can be used as basis: They
already laid a solid basis for statistical analysis and are working on a
system that allows to cherry-pick revisions, change-sets and compare
those. However AFAIK it runs in virtual-machine which makes it useless
for testing rt performance, but there may be options to use it on
bare-metal.
IMHO low-latency is quite overrated. There are few use-cases that
actually require it. If one really needs reliable low-latency (lets say
<20ms) - s/he needs a realtime-kernel (and for live-performances also
some other tweaks e.g. disable updated).
A RT-linux system either works or it does not. The performance
differences between different working rt-kernel revisions are usually
quite subtle, and it is always possible to overload the system because
of hardware limitations.
For benchmarking different kernel revisions/systems: I suggest to stick
to the rt-test tools such as hwlatdetect, cyclictest, pi_stress etc.
Something that would be useful to have is a jack-audio stress-test suite!
After installing a new system or getting new hardware: automatically run
some tests to check the limits of the system.
ardour's jacktest.c is a first step in that direction (testing CPU/DSP
load). It could be supplemented by an I/O test tool (read audio-files
from disk). An extended version of latentor, that uses jack_delay to
find the lowest possible latency with no x-runs may be a 3rd, etc
But that information would only be useful for you, not for others.
2c,
robin
6:03 p.m.
On 12/12/2010 05:17 PM, Robin Gareus wrote:
long-answer and brainstorm:
The question is whether it is worth the time to make it, and what can be
learned from the information.
End-users won't learn much from those statistics. Unless you have
exactly the same hardware, it is close to impossible to draw
conclusions. One would need to
a) isolate the correlating factors and there are certainly much more
than just the kernel-revision, flavor, CPU-speed and audio-interface.
b) find values that can be measured reliably.
eg. what would you learn from information such as:
With kernel A on system B using sound-card C and jack-settings D
one can run for>=X seconds without an x-run.
where D is chosen to maximize X while f.i. minimizing latency.
Besides there is no common goal: some end-users require huge I/O (read
128 audio tracks from disk). Others only need one channel but low
latency, yet others only CPU power for effect-processing.
As for making something that is useful for developers: compare different
versions, do regression tests on the same system. It will take huge
effort to pull it off. Maybe the Phoronix can be used as basis: They
already laid a solid basis for statistical analysis and are working on a
system that allows to cherry-pick revisions, change-sets and compare
those. However AFAIK it runs in virtual-machine which makes it useless
for testing rt performance, but there may be options to use it on
bare-metal.
IMHO low-latency is quite overrated. There are few use-cases that
actually require it. If one really needs reliable low-latency (lets say
<20ms) - s/he needs a realtime-kernel (and for live-performances also
some other tweaks e.g. disable updated).
This is what I am thinking too. Which is why I think rt-kernels should
only be recommended to those users who need them, considering that
rt-kernels often cause non audio-related issues (problems installing
graphic drivers, etc).
Then there is the developers point of view. To whom and for what end are
they maintaining rt-kernels?
A RT-linux system either works or it does not. The
performance
differences between different working rt-kernel revisions are usually
quite subtle, and it is always possible to overload the system because
of hardware limitations.
For benchmarking different kernel revisions/systems: I suggest to stick
to the rt-test tools such as hwlatdetect, cyclictest, pi_stress etc.
Something that would be useful to have is a jack-audio stress-test suite!
After installing a new system or getting new hardware: automatically run
some tests to check the limits of the system.
ardour's jacktest.c is a first step in that direction (testing CPU/DSP
load). It could be supplemented by an I/O test tool (read audio-files
from disk). An extended version of latentor, that uses jack_delay to
find the lowest possible latency with no x-runs may be a 3rd, etc
But that information would only be useful for you, not for others.
2c,
robin
--
ailo
6:33 p.m.
On 12/12/2010 06:12 PM, Fabio wrote:
uninstalled my RT-Kernel because since 2.6.35 and now
with 2.6.36 I get LOWER latencies with them than with 2.6.33-RT
I don't doubt that, RT is usually slower due to overhead. But it's much
more reliable especially so when you move towards the limits of the system.
2c,
robin
6:42 p.m.
Hi,
I would go with what Robin said. That being said, Robin's tweaks on
Transmission last year on 89 set the pace for our build (brilliant!). Since
then tuning jack2 (jackdmp) Rui's rtirq, plus tuning for specific chips /
computer hardware makes a difference. If you want something now that truly
stands up and has had some of the best Linux developers touch the project,
go with Transmission 4.2. I know Paul will jump in and tune us all up with
our thoughts (go Paul!) but it should be stated again we are getting lights
out performance without RT on our new multi-touch Tablets for Pro Audio with
2.6.35, Meego/AtomN450.
Lastly, Transmission is only $39.00 for LAD and LAU (insert cheap plug here)
and that covers our license agreement payments to our partners, support, and
ongoing development.
Another cheap plug is we are about to launch and open the beta program for
the tablet and the interest has been amazing!!!
www.indamixx.com
Thank you
Ronald Stewart
Creative Director
Trinity Audio Group Inc.
9854 National Blvd. #322
Los Angeles CA 90034
310-733-9285
ronaldjstewart(a)gmail.com
On Sun, Dec 12, 2010 at 9:12 AM, Fabio <capoeirista(a)arcor.de> wrote:
Em domingo 12 dezembro 2010, às 14:17:15, Robin Gareus
escreveu:
If one really needs reliable low-latency (lets
say
<20ms) - s/he needs a realtime-kernel
I uninstalled my RT-Kernel because since 2.6.35 and now with 2.6.36 I get
LOWER latencies with them than with 2.6.33-RT
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
7:22 p.m.
On 12/12/2010 06:42 PM, Ronald Stewart wrote:
Hi,
I would go with what Robin said. That being said, Robin's tweaks on
Transmission last year on 89 set the pace for our build (brilliant!). Since
then tuning jack2 (jackdmp) Rui's rtirq, plus tuning for specific chips /
computer hardware makes a difference. If you want something now that truly
stands up and has had some of the best Linux developers touch the project,
go with Transmission 4.2. I know Paul will jump in and tune us all up with
our thoughts (go Paul!) but it should be stated again we are getting lights
out performance without RT on our new multi-touch Tablets for Pro Audio with
2.6.35, Meego/AtomN450.
So with 2.6.35 rtirq also works with a non real-time kernel?
Best,
Jeremy
7 Jan
7 Jan
1:32 p.m.
On Sun, Dec 12, 2010 at 07:22:28PM +0100, Jeremy Jongepier wrote:
On 12/12/2010 06:42 PM, Ronald Stewart wrote:
i am not aware of normal kernels having threaded irq handlers.
additionally jack2 does not mlockall clients.
so basically i would say, that this configuration works is pretty much
luck.
maybe robin can clarify this.
Hi,
I would go with what Robin said. That being said, Robin's tweaks on
Transmission last year on 89 set the pace for our build (brilliant!). Since
then tuning jack2 (jackdmp) Rui's rtirq, plus tuning for specific chips /
computer hardware makes a difference. If you want something now that truly
stands up and has had some of the best Linux developers touch the project,
go with Transmission 4.2. I know Paul will jump in and tune us all up with
our thoughts (go Paul!) but it should be stated again we are getting lights
out performance without RT on our new multi-touch Tablets for Pro Audio with
2.6.35, Meego/AtomN450.
So with 2.6.35 rtirq also works with a non real-time kernel?
Best,
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
torben Hohn
2:43 p.m.
On 01/07/2011 01:32 PM, torbenh wrote:
On Sun, Dec 12, 2010 at 07:22:28PM +0100, Jeremy
Jongepier wrote:
No it they do not.
On 12/12/2010 06:42 PM, Ronald Stewart wrote:
i am not aware of normal kernels having threaded irq handlers. Hi,
I would go with what Robin said. That being said, Robin's tweaks on
Transmission last year on 89 set the pace for our build (brilliant!). Since
then tuning jack2 (jackdmp) Rui's rtirq, plus tuning for specific chips /
computer hardware makes a difference. If you want something now that truly
stands up and has had some of the best Linux developers touch the project,
go with Transmission 4.2. I know Paul will jump in and tune us all up with
our thoughts (go Paul!) but it should be stated again we are getting lights
out performance without RT on our new multi-touch Tablets for Pro Audio with
2.6.35, Meego/AtomN450.
So with 2.6.35 rtirq also works with a non real-time kernel? additionally jack2 does not mlockall clients.
If the machine as enough RAM or no SWAP partition this won't be a problem.
The ability to distribute audio load over multiple CPU cores is a big
pro. (tschak was not packaged when building the Transmission disto and
we were somewhat conservative, as well).
so basically i would say, that this configuration
works is pretty much
luck.
Vanilla kernels > 2.6.33 do offer great overall performance: smooth
Destkop and acceptable audio performance. Peak performance is for sure
better than with the latest RT kernel (2.6.33.7.2-rt30).
However that it works _reliable_ is indeed luck.
maybe robin can clarify this.
I don't know the details for the new Indamixx tablets, maybe the
sound-card (and USB ports for external audio interfaces) are on a
dedicated IRQ (they were not on the first generation Indamixx netbooks:
the audio IRQ was shared with the graphics card and WiFi; a RT kernel
and rtirq was pretty much a requirement)
I don't think reliable low latency is a major goal for Indamixx. Most
use-cases are quite fine with high latency that can be compensated for.
Also see an article I'm just writing with Luis:
http://wiki.linuxaudio.org/wiki/jack_latency_tests#does_latency_really_real…
An occasional rare x-run is probably sth. Indamixx users can live with.
After all it is a portable studio, not something super-pro-high-end to
be mounted in a studio or used on-stage. Besides overall performance is
for sure better than on comparable windows products even without RT kernel.
FWIW: Thomas Gleixer has announced that he's working on a RT patch for
2.6.37 but there's no ETA.
ciao,
robin
Best,
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
6:42 p.m.
Hi again,
OOPS, I made lots of typos in that email this morning (please do send
some coffee). I hope you understood the content of it anyway. If not:
please excuse my sloppiness and read on:
best,
robin
On 01/07/2011 02:43 PM, Robin Gareus wrote:
s/as/has/
s/Destkop/Desktop/
On 01/07/2011 01:32 PM, torbenh wrote:
The vanilla kernel (<=2.6.37 - currently latest version) has no threaded
IRQ handlers and does not support rtirq.
On Sun, Dec 12, 2010 at 07:22:28PM +0100, Jeremy
Jongepier wrote:
No it they do not. On 12/12/2010 06:42 PM, Ronald Stewart wrote:
i am not aware of normal kernels having threaded irq handlers. Hi,
I would go with what Robin said. That being said, Robin's tweaks on
Transmission last year on 89 set the pace for our build (brilliant!). Since
then tuning jack2 (jackdmp) Rui's rtirq, plus tuning for specific chips /
computer hardware makes a difference. If you want something now that truly
stands up and has had some of the best Linux developers touch the project,
go with Transmission 4.2. I know Paul will jump in and tune us all up with
our thoughts (go Paul!) but it should be stated again we are getting lights
out performance without RT on our new multi-touch Tablets for Pro Audio with
2.6.35, Meego/AtomN450.
So with 2.6.35 rtirq also works with a non real-time kernel? additionally
jack2 does not mlockall clients.
If the machine as enough RAM or no SWAP partition this won't be a problem. The ability to distribute audio load over multiple CPU
cores is a big
pro. (tschak was not packaged when building the Transmission disto and
we were somewhat conservative, as well).
s/tschak/tschack/
so basically i
would say, that this configuration works is pretty much
luck.
Vanilla kernels > 2.6.33 do offer great overall performance: smooth
Destkop and acceptable audio performance. Peak performance is for sure
better than with the latest RT kernel (2.6.33.7.2-rt30). However that it works _reliable_ is indeed luck.
--
Robin Gareus
web: http://gareus.org/ mail: robin(a)gareus.org
lab: http://citu.fr/ chat: xmpp:rgareus@ik.nu
Public Key at http://pgp.mit.edu/ http://gareus.org/public.asc
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
maybe robin can clarify this.
I don't know the details for the new Indamixx tablets, maybe the
sound-card (and USB ports for external audio interfaces) are on a
dedicated IRQ (they were not on the first generation Indamixx netbooks:
the audio IRQ was shared with the graphics card and WiFi; a RT kernel
and rtirq was pretty much a requirement)
I don't think reliable low latency is a major goal for Indamixx. Most
use-cases are quite fine with high latency that can be compensated for.
Also see an article I'm just writing with Luis:
http://wiki.linuxaudio.org/wiki/jack_latency_tests#does_latency_really_real…
An occasional rare x-run is probably sth. Indamixx users can live with.
After all it is a portable studio, not something super-pro-high-end to
be mounted in a studio or used on-stage. Besides overall performance is
for sure better than on comparable windows products even without RT kernel.
FWIW: Thomas Gleixer has announced that he's working on a RT patch for
2.6.37 but there's no ETA.
ciao,
robin
>> Best,
>>
>> Jeremy
>> _______________________________________________
>> Linux-audio-user mailing list
>> Linux-audio-user(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
7:30 p.m.
On Fri, Jan 07, 2011 at 02:43:27PM +0100, Robin Gareus wrote:
RT is only about reliability :)
i know that latency doesnt really matter.
but for live FX and synths, it does matter.
thats probably a use case, which is not really used with transmission.
On 01/07/2011 01:32 PM, torbenh wrote:
hmm... with enough ram yes.
note that even without swap executable files are mmapped into the
processes addressspace, these pages can be dropped instantly, because
they already reside on disk. kernel likes doing that.
but with enough ram, you can assume most of the time, that ld.so faulted
the pages in, and they are going to remain mapped.
On Sun, Dec 12, 2010 at 07:22:28PM +0100, Jeremy
Jongepier wrote:
No it they do not.
On 12/12/2010 06:42 PM, Ronald Stewart wrote:
i am not aware of normal kernels having threaded irq handlers. Hi,
I would go with what Robin said. That being said, Robin's tweaks on
Transmission last year on 89 set the pace for our build (brilliant!). Since
then tuning jack2 (jackdmp) Rui's rtirq, plus tuning for specific chips /
computer hardware makes a difference. If you want something now that truly
stands up and has had some of the best Linux developers touch the project,
go with Transmission 4.2. I know Paul will jump in and tune us all up with
our thoughts (go Paul!) but it should be stated again we are getting lights
out performance without RT on our new multi-touch Tablets for Pro Audio with
2.6.35, Meego/AtomN450.
So with 2.6.35 rtirq also works with a non real-time kernel? additionally jack2 does not mlockall clients.
If the machine as enough RAM or no SWAP partition this won't be a problem.
The ability to distribute audio load over multiple CPU cores is a big
pro. (tschak was not packaged when building the Transmission disto and
we were somewhat conservative, as well).
sure. if latency doesnt really matter, then that is the right choice.
so basically i would say, that this configuration
works is pretty much
luck.
Vanilla kernels > 2.6.33 do offer great overall performance: smooth
Destkop and acceptable audio performance. Peak performance is for sure
better than with the latest RT kernel (2.6.33.7.2-rt30).
However that it works _reliable_ is indeed luck. maybe robin can clarify this.
I don't know the details for the new Indamixx tablets, maybe the
sound-card (and USB ports for external audio interfaces) are on a
dedicated IRQ (they were not on the first generation Indamixx netbooks:
the audio IRQ was shared with the graphics card and WiFi; a RT kernel
and rtirq was pretty much a requirement)
I don't think reliable low latency is a major goal for Indamixx. Most
use-cases are quite fine with high latency that can be compensated for.
Also see an article I'm just writing with Luis:
http://wiki.linuxaudio.org/wiki/jack_latency_tests#does_latency_really_real…
An occasional rare x-run is probably sth. Indamixx users can live with.
After all it is a portable studio, not something super-pro-high-end to
be mounted in a studio or used on-stage. Besides overall performance is
for sure better than on comparable windows products even without RT kernel.
FWIW: Thomas Gleixer has announced that he's working on a RT patch for
2.6.37 but there's no ETA.
ciao,
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
torben Hohn
Best,
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3:06 p.m.
On Fri, 7 Jan 2011, torbenh wrote:
On Sun, Dec 12, 2010 at 07:22:28PM +0100, Jeremy
Jongepier wrote:
Indamixx/Transmission 4 has a PREEMPT_RT kernel and utilizes
rtirq.
Indamixx 2/Transmission 5 (MeeGo) has a PREEMPT kernel, and
therefore rtirq won't work with it. We've spent a lot of
time tuning this kernel, and while there have been no
clinical tests... we're experiencing performance very close
to Transmission 4's PREEMPT_RT kernel (With jack running at
512x2 frames/buffer and 44100 Hz) on various machines.
We are required by MeeGo to have a kernel >= 2.6.35. In
addition, to use 2.6.33 we would have to backport a
boat-load of device drivers. If an PREEMPT_RT patch appears
for 2.6.35 or 2.6.37, you can bet that we'll be all over it
and doing side-by-side comparisons.
-gabriel
On 12/12/2010 06:42 PM, Ronald Stewart wrote:
i am not aware of normal kernels having threaded irq handlers.
additionally jack2 does not mlockall clients. Hi,
I would go with what Robin said. That being said, Robin's tweaks on
Transmission last year on 89 set the pace for our build (brilliant!). Since
then tuning jack2 (jackdmp) Rui's rtirq, plus tuning for specific chips /
computer hardware makes a difference. If you want something now that truly
stands up and has had some of the best Linux developers touch the project,
go with Transmission 4.2. I know Paul will jump in and tune us all up with
our thoughts (go Paul!) but it should be stated again we are getting lights
out performance without RT on our new multi-touch Tablets for Pro Audio with
2.6.35, Meego/AtomN450.
So with 2.6.35 rtirq also works with a non real-time kernel?
7:14 p.m.
On Fri, Jan 07, 2011 at 08:05:59AM -0600, Gabriel M. Beddingfield wrote:
On Fri, 7 Jan 2011, torbenh wrote:
ahh... 512 is pretty high latency, normal PREEMPT kernels should do that
pretty well.
On Sun, Dec 12, 2010 at 07:22:28PM +0100, Jeremy
Jongepier wrote:
Indamixx/Transmission 4 has a PREEMPT_RT kernel and utilizes rtirq.
Indamixx 2/Transmission 5 (MeeGo) has a PREEMPT kernel, and
therefore rtirq won't work with it. We've spent a lot of time
tuning this kernel, and while there have been no clinical tests...
we're experiencing performance very close to Transmission 4's
PREEMPT_RT kernel (With jack running at 512x2 frames/buffer and
44100 Hz) on various machines. On 12/12/2010 06:42 PM, Ronald Stewart wrote:
i am not aware of normal kernels having threaded irq handlers.
additionally jack2 does not mlockall clients. Hi,
I would go with what Robin said. That being said, Robin's tweaks on
Transmission last year on 89 set the pace for our build (brilliant!). Since
then tuning jack2 (jackdmp) Rui's rtirq, plus tuning for specific chips /
computer hardware makes a difference. If you want something now that truly
stands up and has had some of the best Linux developers touch the project,
go with Transmission 4.2. I know Paul will jump in and tune us all up with
our thoughts (go Paul!) but it should be stated again we are getting lights
out performance without RT on our new multi-touch Tablets for Pro Audio with
2.6.35, Meego/AtomN450.
So with 2.6.35 rtirq also works with a non real-time kernel?
We are required by MeeGo to have a kernel >= 2.6.35. In addition,
to use 2.6.33 we would have to backport a boat-load of device
drivers. If an PREEMPT_RT patch appears for 2.6.35 or 2.6.37, you
can bet that we'll be all over it and doing side-by-side
comparisons.
-gabriel
--
torben Hohn
10:37 p.m.
On Fri, 7 Jan 2011, torbenh wrote:
On Fri, Jan 07, 2011 at 08:05:59AM -0600, Gabriel M.
Beddingfield wrote:
I knew _someone_ would chime in about 23ms being "high
latency." :-)
FWIW, several popular apps (esp. those doing Fourier
Transforms, like time-stretchers) will not work reliably at
<256 frames/period.
-gabriel
Indamixx 2/Transmission 5 (MeeGo) has a PREEMPT kernel, and
therefore rtirq won't work with it. We've spent a lot of time
tuning this kernel, and while there have been no clinical tests...
we're experiencing performance very close to Transmission 4's
PREEMPT_RT kernel (With jack running at 512x2 frames/buffer and
44100 Hz) on various machines.
ahh... 512 is pretty high latency, normal PREEMPT kernels should do that
pretty well.
11:05 p.m.
On 01/07/2011 10:37 PM, Gabriel M. Beddingfield wrote:
On Fri, 7 Jan 2011, torbenh wrote:
LOL, but it is.
As far as I'm concerned personally, when using the computer as
effect-rack playing guitar or bass:
latencies between 10 and 20ms are the worst!
On Fri, Jan 07, 2011 at 08:05:59AM -0600, Gabriel
M. Beddingfield wrote:
I knew _someone_ would chime in about 23ms being "high latency." :-)
Indamixx 2/Transmission 5 (MeeGo) has a PREEMPT kernel, and
therefore rtirq won't work with it. We've spent a lot of time
tuning this kernel, and while there have been no clinical tests...
we're experiencing performance very close to Transmission 4's
PREEMPT_RT kernel (With jack running at 512x2 frames/buffer and
44100 Hz) on various machines.
ahh... 512 is pretty high latency, normal PREEMPT kernels should do that
pretty well. 20ms I can manage and compensate somewhat.
<10ms is fine.
<5ms is great.
I do run jack at 64*2 - jack_delay measures 4.9ms total round-trip
latency. It rocks!
FWIW, several popular apps (esp. those doing Fourier
Transforms, like
time-stretchers) will not work reliably at <256 frames/period.
Would you care to enlighten us which popular apps that are?
'fmit' for example uses FTT and works just fine at 32fpp.
2c,
robin
11:19 p.m.
On Fri, 7 Jan 2011, Robin Gareus wrote:
OK... Yes, in this use case. There's a lot of use cases
where this is acceptable.
Before I FUD someone else's application... a perfect example
is StretchPlayer (using RubberBand). I can't get it to be
RT-safe at <256... and it's marginal at 256.
Maybe I didn't configure it right... ??
-gabriel
I knew
_someone_ would chime in about 23ms being "high latency." :-)
LOL, but it is.
As far as I'm concerned personally, when using the computer as
effect-rack playing guitar or bass:
latencies between 10 and 20ms are the worst! FWIW, several
popular apps (esp. those doing Fourier Transforms, like
time-stretchers) will not work reliably at <256 frames/period.
Would you care to enlighten us which popular apps that are?
'fmit' for example uses FTT and works just fine at 32fpp.
12 Jan
12 Jan
2:04 p.m.
On Friday, January 07, 2011 04:18:57 pm Gabriel M.
Beddingfield wrote:
Before I FUD someone else's application... a
perfect
example is StretchPlayer (using RubberBand). I can't
get it to be RT-safe at <256... and it's marginal at
256.
FYI, I did some testing with RubberBand and found that it
has a fixed minimum processing window/time of 512 frames.
This makes it dangerous to use with <512 frames/period
because it does too much work in one period.
For example, at 64 frames/period I measured these processing
times for subsequent process() cycles:
Process time = 1533 usecs
Process time = 1851 usecs
Process time = 1787 usecs
Process time = 26 usecs
Process time = 18 usecs
Process time = 20 usecs
Process time = 22 usecs
Process time = 19 usecs
Process time = 18 usecs
Process time = 21 usecs
Process time = 22 usecs
Process time = 20 usecs
Process time = 17 usecs
Process time = 18 usecs
Process time = 21 usecs
Process time = 18 usecs
Process time = 21 usecs
Process time = 26 usecs
Process time = 22 usecs
Process time = 27 usecs
Process time = 20 usecs
Process time = 30 usecs
Process time = 27 usecs
Process time = 66 usecs
Process time = 1893 usecs
Process time = 18 usecs
Process time = 29 usecs
Process time = 24 usecs
Process time = 20 usecs
Process time = 18 usecs
Process time = 22 usecs
Process time = 18 usecs
Process time = 1518 usecs
Process time = 20 usecs
Process time = 21 usecs
Process time = 23 usecs
Process time = 21 usecs
Process time = 17 usecs
Process time = 22 usecs
Process time = 21 usecs
Process time = 1654 usecs
I.e. it does all its calculations every 8 periods
(512/64)... instead of doing a little bit in each period.
This behavior makes it dangerous to use RubberBand at less
than 512 frames/period because it eats up your processor
headroom. However, if you have a really fast processor you
can usually get away with it.
It looks like it's possible to make the window smaller by
hacking RubberBand... but I can't figure out how to do it
through the public API.
-gabriel
12 Dec
12 Dec
5:18 p.m.
Also, for me, what is interesting is not exact numbers, but rather a
general concept of how big the difference is between kernels.
Publishing a table of results will also make it possible to know what to
expect from let's say a certain intel atom processor run on a list of
kernels from an example repository.
I gather this could be helpful to the user when choosing hardware and
distro to a project, if the project involves as earlier mentioned one of:
* live audio processing
* monitoring
* using firewire devices
From a practical point of view for someone as
ignorant about the
technical details as myself, I suppose I'm just trying to get a general
idea of what you get from different kernels.
So, I was making outlines on how to do these two things:
1. a test/script for making tests on a single machine to compare
performance on different kernels.
2. results summed up in a table that gives you a general idea of what
you get with different kernels.
There could perhaps be a number of different tables for different
processors, assuming that the processor is the main important factor
that decides the actual latency you get with a kernel.
These tests could then be published in a wiki, if deemed worthy.
- Why such a table should be made, and for who?:
Some practical uses that may require a rt kernel:
* live audio processing (requires low latency)
* monitoring (requires low latency)
* using firewire devices (As far as I understand ffado works best with
-rt kernels)
Possible/impossible?
--
ailo
4863
days inactive
4894
days old
linux-audio-user@lists.linuxaudio.org
22 comments
10 participants
participants (10)
-
ailo -
allcoms -
Fabio -
Gabriel M. Beddingfield -
Jeremy Jongepier -
Peter Plessas -
Robin Gareus -
Robin Gareus -
Ronald Stewart -
torbenh