Re: Questions about virtual ALSA driver (dummy), PortAudio and full-duplex drops

[David Henningsson <david.henningsson@canonical.com>]

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.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic