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
