Subject: Re: [linux-audio-dev] 32/96 x 24 playback improvements, I think
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke helmi 02 2000 - 19:35:04 EST
More results from my experiments:
Juhana asked:
>My engine works the same way than yours and I have wondered if I should
>at all give the splitting to kernel. What is the different in reading
>1 seconds blocks or smaller blocks for 26 tracks simultaneously? Overhead
>in moving from thread to thread, and kernel space to user space?
i reduced the number of read-ahead threads to 1. this works much
better. i thought about this for a while tonight, and it sort of makes
sense to me. in other words, i was spouting BS yesterday about getting
the disk driver to optimize the disk scheduling. i say this was BS because:
a thread asks the filesystem to read X bytes of data.
the filesystem looks in the buffer cache, and finds that its not there.
the filesystem asks the disk driver to put the relevant pages into the cache.
the thread blocks.
OK, so then we could do the same with another thread, and another etc.
But I am guessing (I'm not sure, but then I am not sure about any of
this) that by the time the thread has blocked, the disk driver has
already come up with a new disk schedule and put it in motion. the
fact that the next thread might need blocks that are actually
interleaved with the first thread will not make any difference to the
current disk schedule.
By going down to 1 thread (again!), we reduce the number of context
switches dramatically.
Doing this has enabled me to reduce the h/w buffering by a factor of 4
(down to about 35ms), and has eliminated drop-outs on an otherwise
lightly-loaded machine (and this is without SCHED_FIFO). this is
great.
OK, back to the experiments, and working on how much recording alters
the performance. Since seeks are the killer, and recording doesn't
require any more or less seeking than playback, i hope it won't be
much.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST