> >An examples situation for using priority inheritance > >might be porting a read/write audio i/o application to a > >callback based interface without too much effort. This can\\\\\\\'t in the > >general case be done without adding latency, if there is no blocking > >allowed in the callback function. But why not block? It takes time > > because the main reason for doing this is that the r/w app expects to > be able to generate N1 samples at a time, whereas the callback wants > only N2, and N1>N2. so when you block-to-get-r/w-thread-to-run, you > run the r/w-thread for long enough to generate N1 samples. this > instantly violates real-time constraints based on N2.
That\'s true. This hasn\'t got to do with using a mutex in the process() callback though. > if the code was willing to generate any number of samples at a time, > and write them in any sized chunk, then there would be no need for > such a hack. I agree with you that the only real solution is to rewrite the application. Still, as others said that was not going to happen, the mentioned solution will work as long as the hardware period size isn\'t too different from the number of samples the application processes per read/write. I mentioned this before because I did not think these (read/write) applications are a good reason to have the process() callback use a constant nframes (during jackd lifetime). > it therefore doesn\'t solve the underlying problem: > > * a device driver API that was written to hide the real-time > nature of the device behind the Unix open/read/write/close model > * an application that used the API. > * a desire to run the application in a low latency environment. The latency of these applications can never be lower as the N1 (from above) anyway. But on some of these applications N1 might be set very small at compile time. N1 < N2 isn\'t really a problem. It\'s best to just rewrite these applications to support a callback based audio i/o api natively though. There will always be other uses of priority inheritance :) > its the API that is central here. you\'ve got a device that absolutely > wants a certain amount of data read and/or written every N > msecs. creating an API that allows the app to pretend this is not true > is the root of the problem, IMHO. Again, I agree with you. That\'s also why I am against a constant nframes, because there is hardware that really doesn\'t want nframes constant. --martijn Powered by ASHosting
