[ Moving to port-acorn32, where this is relevant. ]

On Sun, 18 Jan 2004, Chris Gilbert wrote:

> On Sun, 18 Jan 2004 22:58:48 +0000
> Richard Earnshaw <rearnsha@buzzard.freeserve.co.uk> wrote:
> > Oh, and thanks to Ben too, the 16-bit sound code on a RISC PC is
> > working fine as well...  (well, I get the odd dropout when using
> > audioplay, but I think that's just a lack of read-ahead on the disk --
> > if the file is in memory then it's fine).
>
> Could be interrupt contention,

Shouldn't be.  vidcaudio(4) does very little in its interrupt handler,
and all the heavy data-transfer in audio(4) should happen in the top half
with interrupts enabled.  splbio is less than splaudio, so audio
interrupts should carry on while the disk operation is in progress.
Certainly my experience is that vidcaudio interrupts are always handled in
time.

I think the problem is just the UVM isn't reading ahead far enough.
audioplay mmap()s the file and write()s it to /dev/audio, so it relies on
UVM's read-ahead quite heavily.

-- 
Ben Harris                                                   <bjh21@NetBSD.org>
Portmaster, NetBSD/acorn26           <URL:http://www.NetBSD.org/Ports/acorn26/>