On Wed, Nov 4, 2009 at 7:52 AM, Tim Blechmann <tim@xxxxxxxxxx> wrote: >> I'm not a developer and cannot really address your specific >> question but for my use of the rt-kernel I put important rt-audio >> files on a 1394 drive and give the 1394 driver higher priorities using >> the IRQ scheduling tools. I don't have any trouble running 2 or 3 1394 >> drives recording and playing back 48 channels in Ardour. >> >> While I agree you should do everything the right way technically in >> the code maybe part of your solution is outside of the app you are >> writing and in the use of these support tools? > > well, if i understand the rt howto correctly, _no_ disc access is > allowed, neither from rt nor from non-rt threads, since it may produce > page faults, which introduce latencies ... > according to this definition, ardour is not an rt-safe application ... > as for rt-safety, i prefer analyzing the latency hotspots instead of > relying on test results > > tim > > -- > tim@xxxxxxxxxx > http://tim.klingt.org > > Avoid the world, it's just a lot of dust and drag and means nothing in > the end. > Jack Kerouac In the limit you may be right. Possibly unbounded disk IO would never be real-time safe. However in practice I see xruns when I use normal priorities and none when I give my 1394 driver higher priorities. Logically it doesn't make sense to me that *no* disk access is allowed. I think the rt-threads just do their work and the drives catch up when they can. Apps like Ardour are reading and writing the hard drive all the time. Lots of files are open and streaming, in my case maybe 40 files running for hours. I think that disk access in an rt-thread make no sense at it cannot response real-time, but non-rt disk activity just gets interrupted like any other non-rt process, right? Good luck with what you are up to. Cheers, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
