Re: [linux-audio-dev] 32/96 x 24 playback improvements, I think

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] 32/96 x 24 playback improvements, I think
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe helmi  04 2000 - 21:45:56 EST


>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).

hmm. nice argument. i haven't run into this particular problem on my
machine, but its a compelling argument. but definitely fdatasync, not
fsync.

>The problem of concurrent disk access is that you do not have
>any guarantee that one disk operation will be scheduled before
>another.

Yes, and thats why SCSI is a winner over IDE. It still doesn't allow
you to order the disk requests in the "correct" way, but unless the
disk request queue exceeds the length allowed by the SCSI controller,
you can block the thread immediately and go off and do something else,
rather than (with IDE) having to wait for the current disk request to
be completed by the controller before submitting it (or something like
that).

>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.

i love this phrasing.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST