Subject: Re: [linux-audio-dev] 32/96 x 24 playback improvements, I think
From: Benno Senoner (sbenno_AT_gardena.net)
Date: pe helmi 04 2000 - 20:23:53 EST
On Sat, 05 Feb 2000, Juhana Sadeharju wrote:
> >From: Benno Senoner <sbenno_AT_gardena.net>
> >
> >But the funny thing would be to browse the web and do HD recording on the
> >SAME disk. :-)
> >but linux lacks the realtime disk scheduler, therefore we HAVE to use 2 disk,
> >wheter we use SCSI or not.
>
> Sorry for sounding a repeater but I have to mention yet again that earlier
> I was not even able to record 44100 Hz, stereo, 16-bit audio without
> dropouts. After adding that fsync() trick, I were simultaneously able to
> read PDFs and copy a few files -- all on the same disk -- without any
> dropouts. fsync() gives more disk priority for recording process without
> using soft-RT or such.
>
> Juhana
Yes, but Paul and me were talking about maximizing disk bandwidth,
while your drop-out problem is the usual
"audio writing thread isn't unable to refill audio buffers in time, because
the large disk flush causes an overall stall of several hundreds of msecs"
With the low-latency patches this isn't an issue , but
I was thinking about using fdatasync() at regular intervals, in order to
avoid that a large buffer flush to disk would cause a long stall of the
disk-reader thread therefore causing potential disk read buffer
(should be hundreds of KB/track) underruns,
(not audio playback playback buffer).
The problem of concurrent disk access is that you do not have
any guarantee that one disk operation will be scheduled before
another.
Therefore if the disk syncs a very large amount of buffers
(because you are running on a 512MB box),
the disk reader has just to wait for the completion of the operation.
and meanwhile sh*t can happen.
:-)
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST