Why do you need to avoid entering the kernel? Kernel entry+exit is on
the order of 1 microsecond.
> and without doing additional copies.
That seems reasonable if you're moving a lot of data.
> A common (and AFAIK needed) trick used reading from an audio device is
> to mark the buffer with a special pattern before the hardware fill it,
> so to be aware of the work done when this is overwritten.
Ew. 99.9% reliable.
> We'll appreciate any comments, we don't ask anything better than you
> educate us to do the *clean* thing.
How small does your latency have to be?
Two clean solutions with ~200us + inter-fragment fill and interrupt
latency:
- An ioctl() "wait until audio device is ready to read". Are you
aware that recent work gets SCHED_FIFO wakeup latency reliably
within "+/-200usecs" on someone's x86 box so you shouldn't need to
busy wait for a pattern in a pattern buffer?
- Instead of busy waiting on a pattern, have the kernel update an
mmaped byte counter (read-only to user space). Then you just wait
for the counter to pass a certain value.
They both rely on interrupts from the sound hardware on completion of
each fragment of course, which implies inter-fragment latency. You
can't chase the hardware fill word by word this way.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/