tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Audio buffer positions



damien%zamaudio.com@localhost (Damien Zammit) writes:

>Can we use the arrival of audio IRQs to trigger the measurement of
>current buffer positions and high resolution timer timestamp combined with system time,
>and use these measurements to synchronise a delay-locked-loop (DLL)
>to provide sub-sample accurate estimates of buffer position in between the arrival of audio IRQs?

Not sure what a "sub-sample" buffer position would be.

Currently you get the position with "block" precision, and for regular
hardware that's "sampling the buffer pointer in the audio interrupt".

The "block" size is automatically chosen according to the configured
latency parameter (within bounds), the default precision is 40ms. Reduce
it to 4ms (with sysctl) and the result is good enough for anything and
the overhead is still rather small (does a VAX have audio?).

What you could do is interpolate the buffer pointer using the system
time and the configured bitrate, you need to be careful to keep
it monotonic.

Here is a patch that does this:

http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/audio.diff

It adds a sysctl node that lets you chose 3 modes to calculate the
buffer position.

0 - report the buffer start
1 - interpolate between start and end using time / bitrate
2 - report the buffer end (that's the unpatched behaviour)


The interpolation mode gets you precise timing... if your application uses
the buffer offset correctly. But it won't help for others that just
want precise wakeup times. For these you actually need the smaller buffers.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."


Home | Main Index | Thread Index | Old Index