On 08/06/2013 12:59 PM, Clemens Ladisch wrote:
Smilen Dimitrov wrote:
On 2013-07-25 10:37, Clemens Ladisch wrote:
Your driver's .pointer callback must report the *actual* position at which the hardware has finished reading from the buffer
... for a playback stream, or finished reading, for a capture stream.
Hi Clemens,
I'm not involved with Smilen but still find the questions interesting, so as always, thanks for sharing your knowledge :-)
What if the pointer granularity is very coarse? E g, some hardware might only be able what period you're in (IIRC, I've seen this on the Tegra platform), rather than the actual sample. Would you recommend to report the latest period boundary in that case, or interpolating it with timers?
This is also interesting to PulseAudio which likes to rewind buffers and so on, and relies on a good pointer granularity.
The card then, uses it's own clock, which is not burdened with anything else but filling buffers, meaning we can expect tight timing here; and when it generates an IRQ, it is handled by kernel with highest priority - ergo, not so much jitter. Timer functions, on the other hand, run in softIRQ context - meaning they (and their scheduling) could be preempted by the hardware IRQ of any other device on the system; ergo, more jitter. Is this reasonable to assume?
Yes, but other hardware interrupts interfere only if other devices are used at the same time.
Also, it applies to kernel-space only. If you want to process anything in userspace, you can still be interrupted by any kernel process - hardIRQ, softIRQ or even other kernel tasks.