Re: [linux-audio-user] Re: favorite window Manager for making music?

From: Lee Revell <rlrevell@email-addr-hidden-job.com>
Date: Sun Feb 26 2006 - 03:11:49 EET

On Wed, 2006-02-22 at 21:02 -0600, Jan Depner wrote:
> On Tue, 2006-02-21 at 22:27 -0500, Lee Revell wrote:
> > 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.
> >
>
> 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.
>

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
Received on Sun Feb 26 20:21:44 2006

This archive was generated by hypermail 2.1.8 : Sun Feb 26 2006 - 20:21:44 EET