> Yes and no. We aren't chasing our tail, but that's because the
> application is suppossed to call the GETOPTR ioctl in order to trigger
> a pointer update. In short, the GETOPTR ioctl is our cue that the
> application knows about the empty space and will fill it. We can
> always make the thing chase it's tail unconditionally, but then you
> risk playing total garbage when the application falls behind :-/
This is what happens under most of the drivers i've played quake with
(under DOS too, I think). OSS and OSS/Free, and most of the other PCI
drivers I've looked at, I believe they don't actually program the DMA
engine during GETOPTR calls. Actually one could argue that in the case
of quake it's better to let it chase its tail indefinitely (that's what
they seem to have assumed when they wrote the game anyway according to
comments in the source code) because that allows ambient sounds to
continue uninterrupted during some slowdown, eg possible network
congestion. (The side effect is that sometimes you end up with endlessly
repeating weapon sound effects if you fire during congestion but of
course that coincidence happens less often than congestion itself)
> I see no reason to drain the dac on close for mmaped stuff. The
> application can check GETOPTR to see if the last stuff has played if
> it really cares that much. I'm going to skip the drain_dac() calls on
> mmap from now on. That will solve that problem (and it's also the
> right thing to do if we are chasing our tail and have set the software
> pointer to God only knows where as far as the final sounds are
> concerned).
yep...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/