[linux-audio-dev] Linux Alsa Audio over 1394 - a Thesis

[Martijn Sipkema]

[...]
> >I don't think an application should ask for a certain number of frames
> >to wakeup. The driver should dictate when to wake up. This is the way
> >my Audiowerk8 JACK driver works and it would get a lot more
> >complicated if I had to add support for user-space wake up at
> >arbitrary intervals.
>
> thats because you decided to write a simple driver that didn't fit
> into the ALSA scheme.

Because I think ALSA does too much in the kernel (and it is not
well documented eiter).

> the ALSA scheme deliberately offers such
> capabilities, partly to handle devices like USB audio interfaces. if
> you had written your driver as part of ALSA, it would not have to have
> support for this - the "midlevel" ALSA code takes care of that stuff.

One of the reasons I did not write an ALSA driver is because it supports
all this.

> something has to specify when to wake a task blocked on I/O to the
> device. you can wake it up every interrupt, every N seconds, or every
> N frames (with frames-per-interrupt level resolution). ALSA allows you
> to do any of these. which one is most appropriate, and whether it


This makes ALSA unnecessarily complicated and puts too much in the
kernel IMHO.

> should be set by a "control" application (common on windows/macos) or
> by the application using the device driver is subject to reasonable
> disagreement by sensible people.

I think buffer size should be set by a "control" application or just read
from
a file by the user space driver or possibly even set at module loading.

> >> and the interrupts occur at 420,
> >> 840 and 1260 frames, then we should be woken up on the third
> >> interrupt, process 1024 frames of data, and go back to sleep.
> >
> >This will not perform well since the available processing time per
> >sample will fluctuate.
>
> agreed. but by the same argument, if the variability in the block size
> was too great, we would also see too much variation in
> cycles-per-frame due to processing overhead per interrupt, which will
> also kill us.
>
> so the question seems to be: how much variation is acceptable, and
> what should be responsible for handling it? a device which interrupted
> at random intervals would simply not work; one that interrupts at 420
> frames +/- 5 frames might be OK. should the h/w driver hide the
> variation, or should each application be willing to deal with it?

A decent device will not have more than a few % variance, maybe up
to 10-15% when using varispeed, but that's unavoidable (constant size
callbacks will differ in available processing time then).

> most applications would have no problem, but there is an interesting
> class of applications for whom it poses a real problem that i think
> requires a common solution. i'm not sure what that solution should be.

Using asynchronous processing is a solution. A EDF scheduler would
be nice for this.

--ms