On Sat, 22 Jan 2005 17:00:10 -0500
Paul Davis <paul@email-addr-hidden> wrote:
> >Lee Revell <rlrevell@email-addr-hidden-job.com> writes:
> >> http://kerneltrap.org/node/4406
> >
> >By all means play around with this. But, maintain a healthy
> >skepticism about it. I seriously doubt any of it is worth worrying
> >about until after realtime CPU scheduling is rock solid (which is
> >clearly not the case yet).
well, it is pretty much "good enough" for recording with periodsizes
like 1024 frames.
>
> well, given the seriousness of the errors that occur in the case that
> florian described, and the absence of xruns in his test cases, there
> is an entirely different issue here, one that seems to be totally
> disk-centric.
Well, i should describe why i asked this question in the first place. i
played around with multitrack recordings of 16 or 24 tracks, and in
these cases a simple
find /
can cause disk io starvation to ardour. Sure, one could argue: "well,
don't run find /", but i think it would be great to be able to make some
process _always_ get io before any other process.
The io priorities look promising, but they kinda compare to nice values.
Something like SCHED_FIFO for disk io would really be needed to, to
provide really high reliable recording..
flo
-- Palimm Palimm! http://affenbande.org/~tapas/Received on Sun Jan 23 04:15:09 2005
This archive was generated by hypermail 2.1.8 : Sun Jan 23 2005 - 04:15:09 EET