21 Mar
2013
21 Mar
'13
4:29 p.m.
Can someone who keeps up with RT development help me find up to date
information?
There do not seem to be any RT patches for 3.8 in the usual place (which
as far as I know is still
https://www.kernel.org/pub/linux/kernel/projects/rt/ ).
I found a message from Fernando several months back mentioning that there
was some kind of NFS bug in the 3.6-RT kernel, which is why CCRMA kernels
are still based on 3.4, but despite searching lkml.org with various words
and phrases, I have not been able to piece together any coherent
information on the current state of 3.6 RT kernels, and why there is yet
no 3.8 patch set.
Is this just a case of the RT development community being rather small, so
no one sees a need to make an announcement to LKML that 3.8-RT has some
problems, so don't expect an RT release very soon after the mainline 3.8
release? Or am I just looking in the wrong places for information?
thanks,
Chris Caudle
21 Mar
21 Mar
4:51 p.m.
You can always start from https://www.kernel.org/ .
Current path is https://www.kernel.org/pub/linux/kernel/projects/rt/ .
Yes, the last kernel is
https://www.kernel.org/pub/linux/kernel/projects/rt/2.6.33/ , IMO not
unusual that the patch is behind current vanilla kernel version.
I can't speak for NFS, but at least apart from that 3.6 kernels seem to
be ok. If you need NFS and it should be buggy, can't you use an older
version or the current kernel full preempted with threadirqs? I still
prefer the Kernel-rt, but to be honest, a full preempt kernel with
threadirqs, if any, just makes a minimal difference.
YMMV,
Ralf
6:14 p.m.
On 03/21/2013 08:28 AM, Chris Caudle wrote:
Can someone who keeps up with RT development help me
find up to date
information?
There do not seem to be any RT patches for 3.8 in the usual place (which
as far as I know is still
https://www.kernel.org/pub/linux/kernel/projects/rt/ ).
The latest version of the patch is 3.6.11-rt30 (and the previous one is
3.4.33-rt47). No patches for 3.8.x have been announced or posted AFAIK.
We'll have to be patient...
https://www.kernel.org/pub/linux/kernel/projects/rt is the right place
to look for patches...
I found a message from Fernando several months back
mentioning that there
was some kind of NFS bug in the 3.6-RT kernel, which is why CCRMA kernels
are still based on 3.4, but despite searching lkml.org with various words
and phrases, I have not been able to piece together any coherent
information on the current state of 3.6 RT kernels, and why there is yet
no 3.8 patch set.
There is a mailing list for the rt patches here:
linux-rt-users(a)vger.kernel.org
http://vger.kernel.org/vger-lists.html#linux-rt-users
That is where announcements usually go (new versions, patches, etc).
Is this just a case of the RT development community
being rather small, so
no one sees a need to make an announcement to LKML that 3.8-RT has some
problems, so don't expect an RT release very soon after the mainline 3.8
release? Or am I just looking in the wrong places for information?
You are looking at the right places (except for the linux-rt-users list
which you don't mention). It takes time, I don't know what is holding up
the 3.8.x patches if anything.
BTW, the NFS bug is very specific for the usage I need, but other than
that it seems to perform perfectly in my limited tests.
-- Fernando
22 Mar
22 Mar
6:21 p.m.
By the way, I'd been hearing lots of bad things the past month or two
about unpatched kernels' realtime performance after about 3.3 or so
(some say even earlier). How is that lately? What's the most recent
vanilla kernel that's been known to behave well now?
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
6:47 p.m.
jfyi
3.4.36-rt50 is out today.
running fine here, a lot better than 3.8.4+threadirqs
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
29 Mar
29 Mar
10:48 p.m.
Le 22-03-2013 13:52, Ralf Mardorf a écrit :
On Fri, 2013-03-22 at 18:49 +0100, Ralf Mardorf
wrote:
Just about to install what I think is a real-time linux kernel on the
Linux Mint installation at home. Mint offers low latency kernels such
as 3.5.0.25. No RT kernel in sight it seems. Are the low latency
kernels just another term for real-time kernels ?
On Fri, 2013-03-22 at 17:47 +0000, Rui Nuno
Capela wrote:
My apologies, I missed the point :S. jfyi
3.4.36-rt50 is out today.
^^^ ;) 
10:55 p.m.
jonetsu(a)teksavvy.com wrote:
Are the low latency kernels just another term for
real-time kernels ?
No they are different. For almost all use-cases the low-latency
kernel
is enough, the RT kernels are oriented towards hard real-time
performance. The low latency kernel is capable of at least down to
2ms.. that is probably low enough for your use case?
HTH, -Harry
11 p.m.
Le 29-03-2013 17:55, Harry van Haaren a écrit :
jonetsu(a)teksavvy.com wrote:
Could be, I don't know. This is about recording one instrument at a
time in Ardour, basically.
Are the low latency kernels just another term for
real-time kernels
?
No they are different. For almost all use-cases the low-latency
kernel
is enough, the RT kernels are oriented towards hard real-time
performance. The low latency kernel is capable of at least down to
2ms.. that is probably low enough for your use case? 
11:05 p.m.
On Fri, 29 Mar 2013 23:00:15 +0100, <jonetsu(a)teksavvy.com> wrote:
Le 29-03-2013 17:55, Harry van Haaren a écrit :
As long as you are not doing software monitoring (i.e. listening to what
you are recording through Ardour, while recording it), you don't need low
latency at all, and might not need anything beyond linux-generic.
If you do software monitoring, linux-lowlatency may well be more than
enough.
jonetsu(a)teksavvy.com wrote:
Could be, I don't know. This is about recording one instrument at a time
in Ardour, basically.
Are the low latency kernels just another term for
real-time kernels ?
No they are different. For almost all use-cases the low-latency
kernel
is enough, the RT kernels are oriented towards hard real-time
performance. The low latency kernel is capable of at least down to
2ms.. that is probably low enough for your use case?
30 Mar
30 Mar
11:33 p.m.
On Fri, 29 Mar 2013, Kaj Ailomaa wrote:
As long as you are not doing software monitoring (i.e.
listening to
what you are recording through Ardour, while recording it), you don't
need low latency at all, and might not need anything beyond
linux-generic.
Is this true in all cases, even when using plugins and soft-samplers?
What about if you're sending some of your audio outboard through a mixer
for processing in the hardware world?
The reason I ask is because I am doing monitoring in hardware on an RME
Multiface II, but I'm also sending some channels out to a mixer and
bringing them back. Also at the same time I'm using plugins. I've got
my Jack latency setup to show up in QJackCtl as about 5ms, but it'd be
nicer for the computer if I could use a bigger buffer and not worry
about it.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
31 Mar
31 Mar
midnight
On Sat, 30 Mar 2013 23:33:16 +0100, Brent Busby <brent(a)keycorner.org>
wrote:
On Fri, 29 Mar 2013, Kaj Ailomaa wrote:
As long as you are not doing anything live, using a higher buffer is
recommended as it gives your machine more time to perform the various
calculations needed for your plugins, etc.
If you pass audio out and in again, you will always get some latency, no
matter which buffer setting. I haven't tried it and can't speak for
timing, but if timing is off, you can always adjust that after you've
recorded.
As long as you are not doing software monitoring
(i.e. listening to
what you are recording through Ardour, while recording it), you don't
need low latency at all, and might not need anything beyond
linux-generic.
Is this true in all cases, even when using plugins and soft-samplers?
What about if you're sending some of your audio outboard through a mixer
for processing in the hardware world?
The reason I ask is because I am doing monitoring in hardware on an RME
Multiface II, but I'm also sending some channels out to a mixer and
bringing them back. Also at the same time I'm using plugins. I've got
my Jack latency setup to show up in QJackCtl as about 5ms, but it'd be
nicer for the computer if I could use a bigger buffer and not worry
about it.
3:33 a.m.
New subject: latency - was - what is happening with RT kernel development?
On Sat, March 30, 2013 3:33 pm, Brent Busby wrote:
On Fri, 29 Mar 2013, Kaj Ailomaa wrote:
No matter what kernel you use, a hardware/bios audit makes a difference. I
have done better with just a low latency kernel after tweaking HW, and
bios than I ever did with an RT. (usable audio at 1/2 the latency with
moving the card to a slot with a free irq, another 1/4 the latency with
turning hyperthreading off, yes that is 1/8 all together from 128 f/p to
16 with guitarix running on top in a 10 year old 2.4Gh P4) Turning off
unneeded system services and unloading the kernel modules for unneeded HW
where the bios doesn't allow that also helps. For recording I also use a
higher latency than for live work. Things like ardour are pretty good at
compensating for latency from playback as compared to record. A softsynth
though also delayed before you hear it Is still in time with the audio
track by mixdown and in time with the delayed playback audio for tracking
against. Using outboard HW to modify sound to rerecord would depend on
what kind of modification, delays would not be a problem so long as the
direct sound was not part of it. Real time effects like eq or compression
would be ok for rerecording to it's own track where it could be aligned
before mixing. (I personally do not have any outboard equipment that is as
good as what I have for plugins, your lucky)
I don't know If I have covered your particular use, so the best answer is
to try it and see. If there are problems think if there is a way to fix it
without lowering latency (so long as it isn't more work than it's worth )
and then lower latency until it works.
I try to track with no effects or just use effects for monitoring at a
lower latency (64 or 128) and then move the latency up for mixdown when I
add effects.
--
Len Ovens
www.OvenWerks.net
As long as you are not doing software monitoring
(i.e. listening to
what you are recording through Ardour, while recording it), you don't
need low latency at all, and might not need anything beyond
linux-generic.
Is this true in all cases, even when using plugins and soft-samplers?
What about if you're sending some of your audio outboard through a mixer
for processing in the hardware world?
The reason I ask is because I am doing monitoring in hardware on an RME
Multiface II, but I'm also sending some channels out to a mixer and
bringing them back. Also at the same time I'm using plugins. I've got
my Jack latency setup to show up in QJackCtl as about 5ms, but it'd be
nicer for the computer if I could use a bigger buffer and not worry
about it.
27 Mar
27 Mar
10:51 p.m.
On 03/22/2013 10:56 PM, Fernando Lopez-Lezcano wrote:
On 03/22/2013 10:47 AM, Rui Nuno Capela wrote:
and 3.8.4-rt2 yesterday which I managed to build and seems to run fine
on initial tests (and will be available shortly on Planet CCRMA for
Fedora 18).
-- Fernando
jfyi
3.4.36-rt50 is out today.
running fine here, a lot better than 3.8.4+threadirqs
3.8.4-rt1 was released today :-)
(just read about it)
4330
days inactive
4340
days old
linux-audio-user@lists.linuxaudio.org
15 comments
9 participants
participants (9)
-
Brent Busby -
Chris Caudle -
Fernando Lopez-Lezcano -
Harry van Haaren -
jonetsu＠teksavvy.com -
Kaj Ailomaa -
Len Ovens -
Ralf Mardorf -
Rui Nuno Capela