20 Feb
2006
20 Feb
'06
5:56 p.m.
Quoting Jan Depner <eviltwin69(a)cableone.net>et>:
On Mon, 2006-02-20 at 08:24 -0800, thewade wrote:
I think you can tweak the disk write interupt length so that disk write
sizes are smaller and more frequent, which would effectively solve this
problem.
I think you can do this in /etc/sysconfig/harddisks in Fedora.
Syslogd can be usefull...
There is a hard drive realtime audio howto somewhere on the net: I
remember reading it somewhere... I think Takashi Iwa (I hope I spelled
his name right) wrote something about it when he wrote that latency
motior kernel module tool thingy.
My problems are usually when I have a lot of processing going on and I
switch windows or make a new window or drag windows or something. But I
don't think I have everything set up correctly yet either... Working on
it.
-thewade
Quoting Ismael Valladolid Torres
<ivalladt(a)punkass.com>om>:
This is all well and good but you're only talking about CPU. Disk
I/O is another story entirely. If your WM starts doing some I/O that
you weren't aware of you may get an xrun because you couldn't access the
disk in time. This is the reason that I kill syslogd before I record.
Granted, generally speaking you'll do OK due to the priority of your
process but disk I/O takes a certain amount of time and you can't
interrupt it once it's gone to the disk.
If you're trying to get the lowest latency posible it's dumb having a
desktop system that eats half your resources.
I think what Lee is saying is that with realtime-lsm (and ingo's
spin-locking?), jackd, your audio apps, and limits.conf all set up
right all processes bow to your audio apps. So audio will still get the
lowest latency possible independant of other threads running on your
machine, including the window manager. The screen may not refresh as
frequently or be as responsive, but you should incur no addidional
XRUNS from using one window manager over another.
Am I right?
20 Feb
20 Feb
6:03 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
thewade wrote:
I think you can tweak the disk write interupt length
so that disk write
sizes are smaller and more frequent, which would effectively solve this
problem.
I think you can do this in /etc/sysconfig/harddisks in Fedora.
Syslogd can be usefull...
There is a hard drive realtime audio howto somewhere on the net: I
remember reading it somewhere... I think Takashi Iwa (I hope I spelled
his name right) wrote something about it when he wrote that latency
motior kernel module tool thingy.
And one should put the audio stuff on a separate disk from the OS is
using anyway, preferably on a separate bus (SCSCI, iee1394) if you can.
--
Brett McCoy: Programmer by Day, Guitarist by Night
http://www.alhazred.com
http://www.cassandrasyndrome.com
http://www.revelmoon.com
21 Feb
21 Feb
3:21 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Mon, 2006-02-20 at 13:57 -0800, thewade wrote:
Quoting Jan Depner <eviltwin69(a)cableone.net>et>:
Not when I'm recording someone else's band and xruns make
Linux/Ardour/JACK look bad. There's nothing happening on my system that
I need to know about that badly. Especially after the fact.
On Mon, 2006-02-20 at 08:24 -0800, thewade wrote:
I think you can tweak the disk write interupt length so that disk write
sizes are smaller and more frequent, which would effectively solve this
problem.
I think you can do this in /etc/sysconfig/harddisks in Fedora.
Syslogd can be usefull...
Quoting Ismael Valladolid Torres
<ivalladt(a)punkass.com>om>:
This is all well and good but you're only talking about CPU. Disk
I/O is another story entirely. If your WM starts doing some I/O that
you weren't aware of you may get an xrun because you couldn't access the
disk in time. This is the reason that I kill syslogd before I record.
Granted, generally speaking you'll do OK due to the priority of your
process but disk I/O takes a certain amount of time and you can't
interrupt it once it's gone to the disk.
If you're trying to get the lowest latency posible it's dumb having a
desktop system that eats half your resources.
I think what Lee is saying is that with realtime-lsm (and ingo's
spin-locking?), jackd, your audio apps, and limits.conf all set up
right all processes bow to your audio apps. So audio will still get the
lowest latency possible independant of other threads running on your
machine, including the window manager. The screen may not refresh as
frequently or be as responsive, but you should incur no addidional
XRUNS from using one window manager over another.
Am I right?
There is a hard drive realtime audio howto somewhere
on the net: I
remember reading it somewhere... I think Takashi Iwa (I hope I spelled
his name right) wrote something about it when he wrote that latency
motior kernel module tool thingy.
There's a bunch of information on that on my site (albeit outdated).
Tuning the disk drives is a must and it *will* help but there are
instances where the disk drive is busy and you can't get to it no matter
how well tuned it is. I prefer to minimize any chance of that. You
have to remember that unless you're running RTLinux or VXWorks (or DOS
or VMS) you're not running a hard real time system. Shit happens.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
4:28 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Tue, 2006-02-21 at 13:19 -0600, Jan Depner wrote:
There's a bunch of information on that on my site
(albeit outdated).
Tuning the disk drives is a must and it *will* help but there are
instances where the disk drive is busy and you can't get to it no
matter
how well tuned it is. I prefer to minimize any chance of that. You
have to remember that unless you're running RTLinux or VXWorks (or DOS
or VMS) you're not running a hard real time system. Shit happens.
The -rt kernel with fuill preemption actually is a hard real time system
(no one claims it is in the same league of reliability as QNX or
VXWorks, yet...) - it should be able to guarantee response times.
Of course the best RTOS in the world won't save you from apps that do
disk or GUI stuff in a non RT safe way, or from buggy ACPI
implementations that disappear the CPU out from under the OS for
milliseconds...
Lee
9:32 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Tue, 2006-02-21 at 15:28 -0500, Lee Revell wrote:
On Tue, 2006-02-21 at 13:19 -0600, Jan Depner wrote:
While I agree that it's very good it's not hard real-time. It can't
do guaranteed 15 microsecond interrupt response. It is a very good soft
real-time system.
There's a bunch of information on that on my
site (albeit outdated).
Tuning the disk drives is a must and it *will* help but there are
instances where the disk drive is busy and you can't get to it no
matter
how well tuned it is. I prefer to minimize any chance of that. You
have to remember that unless you're running RTLinux or VXWorks (or DOS
or VMS) you're not running a hard real time system. Shit happens.
The -rt kernel with fuill preemption actually is a hard real time system
(no one claims it is in the same league of reliability as QNX or
VXWorks, yet...) - it should be able to guarantee response times.
Of course the best RTOS in the world won't save
you from apps that do
disk or GUI stuff in a non RT safe way, or from buggy ACPI
implementations that disappear the CPU out from under the OS for
milliseconds...
Yup. I hate it when that happens ;-)
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
9:49 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Tue, 2006-02-21 at 19:30 -0600, Jan Depner wrote:
On Tue, 2006-02-21 at 15:28 -0500, Lee Revell wrote:
Hard RT is not about what the response time is, it's about whether you
can guarantee to make some arbitrary deadline, which the -rt patch can
theoretically do (I say theoretically because you still would have to
audit a limited set of code paths for RT safeness).
On Tue, 2006-02-21 at 13:19 -0600, Jan Depner
wrote:
While I agree that it's very good it's not hard real-time. It can't
do guaranteed 15 microsecond interrupt response. It is a very good soft
real-time system.
There's a bunch of information on that on my
site (albeit outdated).
Tuning the disk drives is a must and it *will* help but there are
instances where the disk drive is busy and you can't get to it no
matter
how well tuned it is. I prefer to minimize any chance of that. You
have to remember that unless you're running RTLinux or VXWorks (or DOS
or VMS) you're not running a hard real time system. Shit happens.
The -rt kernel with fuill preemption actually is a hard real time system
(no one claims it is in the same league of reliability as QNX or
VXWorks, yet...) - it should be able to guarantee response times.
Of course the
best RTOS in the world won't save you from apps that do
disk or GUI stuff in a non RT safe way, or from buggy ACPI
implementations that disappear the CPU out from under the OS for
milliseconds...
Yup. I hate it when that happens ;-)
10:02 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Tue, 2006-02-21 at 20:49 -0500, Lee Revell wrote:
On Tue, 2006-02-21 at 19:30 -0600, Jan Depner wrote:
I beg to differ. Hard real-time guarantees the response time. Most
good hard real-time systems actually do respond in the 10-15 microsecond
range (though that is not a requirement of hard real-time). Theory has
no place in hard real-time. Check with Monta Vista and see if they
think the kernel with RT patches is hard real-time.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
On Tue, 2006-02-21 at 15:28 -0500, Lee Revell
wrote:
Hard RT is not about what the response time is, it's about whether you
can guarantee to make some arbitrary deadline, which the -rt patch can
theoretically do (I say theoretically because you still would have to
audit a limited set of code paths for RT safeness).
On Tue, 2006-02-21 at 13:19 -0600, Jan Depner
wrote:
While I agree that it's very good it's not hard real-time. It can't
do guaranteed 15 microsecond interrupt response. It is a very good soft
real-time system.
There's a bunch of information on that on my
site (albeit outdated).
Tuning the disk drives is a must and it *will* help but there are
instances where the disk drive is busy and you can't get to it no
matter
how well tuned it is. I prefer to minimize any chance of that. You
have to remember that unless you're running RTLinux or VXWorks (or DOS
or VMS) you're not running a hard real time system. Shit happens.
The -rt kernel with fuill preemption actually is a hard real time system
(no one claims it is in the same league of reliability as QNX or
VXWorks, yet...) - it should be able to guarantee response times.
10:14 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Tue, 2006-02-21 at 20:00 -0600, Jan Depner wrote:
On Tue, 2006-02-21 at 20:49 -0500, Lee Revell wrote:
Well, of course, Monta Vista is selling their own RT kernel!
What I mean is that the difference between a hard RT system and a soft
RT system is not between a guaranteed 15us response and a guaranteed
15ms response, it's between the ability to guarantee ANY response time
and only being able to meet the deadline 99.9999999% of the time.
Lee
On Tue, 2006-02-21 at 19:30 -0600, Jan Depner
wrote:
I beg to differ. Hard real-time guarantees the response time. Most
good hard real-time systems actually do respond in the 10-15 microsecond
range (though that is not a requirement of hard real-time). Theory has
no place in hard real-time. Check with Monta Vista and see if they
think the kernel with RT patches is hard real-time.
On Tue, 2006-02-21 at 15:28 -0500, Lee Revell
wrote:
Hard RT is not about what the response time is, it's about whether you
can guarantee to make some arbitrary deadline, which the -rt patch can
theoretically do (I say theoretically because you still would have to
audit a limited set of code paths for RT safeness).
On Tue, 2006-02-21 at 13:19 -0600, Jan Depner
wrote:
> There's a bunch of information on that on my site (albeit outdated).
> Tuning the disk drives is a must and it *will* help but there are
> instances where the disk drive is busy and you can't get to it no
> matter
> how well tuned it is. I prefer to minimize any chance of that. You
> have to remember that unless you're running RTLinux or VXWorks (or DOS
> or VMS) you're not running a hard real time system. Shit happens.
>
The -rt kernel with fuill preemption actually is a hard real time system
(no one claims it is in the same league of reliability as QNX or
VXWorks, yet...) - it should be able to guarantee response times.
While I agree that it's very good it's not hard real-time. It can't
do guaranteed 15 microsecond interrupt response. It is a very good soft
real-time system.
10:58 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Tue, 2006-02-21 at 21:14 -0500, Lee Revell wrote:
On Tue, 2006-02-21 at 20:00 -0600, Jan Depner wrote:
Agreed. For hard real-time I would expect 0 xruns ever and that's
not what I get even with my new system (which is of course tweaked to
within an inch of it's life). I'm pretty happy with the kernel as it is
'cause I sure don't get very many xruns. About one per hour on average
and it's usually just when I'm starting and stopping things. I think I
can live with that ;-)
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
On Tue, 2006-02-21 at 20:49 -0500, Lee Revell
wrote:
Well, of course, Monta Vista is selling their own RT kernel!
What I mean is that the difference between a hard RT system and a soft
RT system is not between a guaranteed 15us response and a guaranteed
15ms response, it's between the ability to guarantee ANY response time
and only being able to meet the deadline 99.9999999% of the time.
On Tue, 2006-02-21 at 19:30 -0600, Jan Depner
wrote:
I beg to differ. Hard real-time guarantees the response time. Most
good hard real-time systems actually do respond in the 10-15 microsecond
range (though that is not a requirement of hard real-time). Theory has
no place in hard real-time. Check with Monta Vista and see if they
think the kernel with RT patches is hard real-time.
On Tue, 2006-02-21 at 15:28 -0500, Lee Revell
wrote:
> On Tue, 2006-02-21 at 13:19 -0600, Jan Depner wrote:
> > There's a bunch of information on that on my site (albeit outdated).
> > Tuning the disk drives is a must and it *will* help but there are
> > instances where the disk drive is busy and you can't get to it no
> > matter
> > how well tuned it is. I prefer to minimize any chance of that. You
> > have to remember that unless you're running RTLinux or VXWorks (or DOS
> > or VMS) you're not running a hard real time system. Shit happens.
> >
>
> The -rt kernel with fuill preemption actually is a hard real time system
> (no one claims it is in the same league of reliability as QNX or
> VXWorks, yet...) - it should be able to guarantee response times.
>
While I agree that it's very good it's not hard real-time. It can't
do guaranteed 15 microsecond interrupt response. It is a very good soft
real-time system.
Hard RT is not about what the response time is, it's about whether you
can guarantee to make some arbitrary deadline, which the -rt patch can
theoretically do (I say theoretically because you still would have to
audit a limited set of code paths for RT safeness).
11:16 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On 2/21/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Tue, 2006-02-21 at 13:19 -0600, Jan Depner wrote:
Just speaking logically, if badly written apps can cause a real-time
kernel to have some xruns, then isn't it true that a badly written WM
could do the same thing?
Either the kernel is safe and handles this stuff or it isn;t 'safe'
and cannot stop it. I understand from other conversations that some
apps are considered to be non-realtime safe. I do not understand how
anyone could ever know that a WM is truly rt safe. How?
Just because one uses Gnome, fluxbox or fvwm and doesn't see xruns is
not proof that it's truly rt safe. You cannot prove a negative,
etc....
- Mark
There's a bunch of information on that on my
site (albeit outdated).
Tuning the disk drives is a must and it *will* help but there are
instances where the disk drive is busy and you can't get to it no
matter
how well tuned it is. I prefer to minimize any chance of that. You
have to remember that unless you're running RTLinux or VXWorks (or DOS
or VMS) you're not running a hard real time system. Shit happens.
The -rt kernel with fuill preemption actually is a hard real time system
(no one claims it is in the same league of reliability as QNX or
VXWorks, yet...) - it should be able to guarantee response times.
Of course the best RTOS in the world won't save you from apps that do
disk or GUI stuff in a non RT safe way, or from buggy ACPI
implementations that disappear the CPU out from under the OS for
milliseconds...
Lee
11:27 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Tue, 2006-02-21 at 19:16 -0800, Mark Knecht wrote:
Just speaking logically, if badly written apps can
cause a real-time
kernel to have some xruns, then isn't it true that a badly written WM
could do the same thing?
When I say badly written apps I am taking about the JACK client's
processing thread. These xruns are not caused by the kernel. If a JACK
client sleeps in the process() callback or tries to do 10ms worth of
work with a 5ms deadline then xruns are inevitable, the best RTOS in the
world will not help you.
Lee
22 Feb
22 Feb
11:04 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Tue, 2006-02-21 at 22:27 -0500, Lee Revell wrote:
On Tue, 2006-02-21 at 19:16 -0800, Mark Knecht wrote:
Yes, it will. In VxWorks, if my interrupt is higher priority than
whatever the application is doing then the application will be
interrupted. Period. That is hard real-time.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
Just speaking logically, if badly written apps
can cause a real-time
kernel to have some xruns, then isn't it true that a badly written WM
could do the same thing?
When I say badly written apps I am taking about the JACK client's
processing thread. These xruns are not caused by the kernel. If a JACK
client sleeps in the process() callback or tries to do 10ms worth of
work with a 5ms deadline then xruns are inevitable, the best RTOS in the
world will not help you.
25 Feb
25 Feb
9:11 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Wed, 2006-02-22 at 21:02 -0600, Jan Depner wrote:
On Tue, 2006-02-21 at 22:27 -0500, Lee Revell wrote:
The -rt patch works exactly the same way. The audio interrupt will fire
and interrupt JACK but you'll still get an xrun if you tried to do 10ms
worth of processing with a 5ms deadline, because the data won't be
ready.
I think we might be talking past each other - unless you are asserting
that in VxWorks, I can try to do 10ms of work in my process() callback
when the deadline is 5ms away and somehow not get an xrun.
An "xrun" does not only refer to the case where the kernel prevents the
deadline from being met - it's also an xrun if the app is stupid and
tries to do something that's impossible to complete by the deadline.
Lee
On Tue, 2006-02-21 at 19:16 -0800, Mark Knecht
wrote:
Yes, it will. In VxWorks, if my interrupt is higher priority than
whatever the application is doing then the application will be
interrupted. Period. That is hard real-time.
Just speaking logically, if badly written apps
can cause a real-time
kernel to have some xruns, then isn't it true that a badly written WM
could do the same thing?
When I say badly written apps I am taking about the JACK client's
processing thread. These xruns are not caused by the kernel. If a JACK
client sleeps in the process() callback or tries to do 10ms worth of
work with a 5ms deadline then xruns are inevitable, the best RTOS in the
world will not help you.
26 Feb
26 Feb
3:31 a.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Sat, 2006-02-25 at 20:11 -0500, Lee Revell wrote:
On Wed, 2006-02-22 at 21:02 -0600, Jan Depner wrote:
You can always *try* to to do 10ms of work in a 5ms slice but it
won't work ;-) I think you're right. I'm talking about the OS as a
whole and you're talking about the application as a single entity. The
application can definitely screw itself. I was thinking in terms of one
application screwing up another one.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
On Tue, 2006-02-21 at 22:27 -0500, Lee Revell
wrote:
The -rt patch works exactly the same way. The audio interrupt will fire
and interrupt JACK but you'll still get an xrun if you tried to do 10ms
worth of processing with a 5ms deadline, because the data won't be
ready.
I think we might be talking past each other - unless you are asserting
that in VxWorks, I can try to do 10ms of work in my process() callback
when the deadline is 5ms away and somehow not get an xrun.
On Tue, 2006-02-21 at 19:16 -0800, Mark Knecht
wrote:
Yes, it will. In VxWorks, if my interrupt is higher priority than
whatever the application is doing then the application will be
interrupted. Period. That is hard real-time.
Just speaking logically, if badly written apps
can cause a real-time
kernel to have some xruns, then isn't it true that a badly written WM
could do the same thing?
When I say badly written apps I am taking about the JACK client's
processing thread. These xruns are not caused by the kernel. If a JACK
client sleeps in the process() callback or tries to do 10ms worth of
work with a 5ms deadline then xruns are inevitable, the best RTOS in the
world will not help you.
21 Feb
21 Feb
11:30 p.m.
New subject: [linux-audio-user] Re: favorite window Manager for making music?
On Tue, 2006-02-21 at 19:16 -0800, Mark Knecht wrote:
Either the kernel is safe and handles this stuff or it
isn;t 'safe'
and cannot stop it. I understand from other conversations that some
apps are considered to be non-realtime safe. I do not understand how
anyone could ever know that a WM is truly rt safe. How?
WMs are not RT anything - a correctly written JACK client will interface
with the GUI in a realtime safe way. If the JACK client tries to do GUI
stuff in the RT thread of course you are screwed.
Just because one uses Gnome, fluxbox or fvwm and
doesn't see xruns is
not proof that it's truly rt safe. You cannot prove a negative,
etc....
These programs do not even enter into the picture - GUI stuff runs at
normal priority and audio stuff at RT priority so it's impossible for
the GUI to block the audio. Unless the app is broken.
Lee
6982
days inactive
6988
days old
linux-audio-user@lists.linuxaudio.org
14 comments
5 participants
participants (5)
-
Brett W. McCoy -
Jan Depner -
Lee Revell -
Mark Knecht -
thewade