26 Feb
2003
26 Feb
'03
1:40 p.m.
;-) I wish you guys had carried this conversation on with a new title as I
think this has nothing at all to do with 1394. ;-)
Just so everyone else not conversing here is clear, the size of the packet
transmitted across the 1394 bus and the size of a Jack data block need have
nothing to do with each other. Using 61883, or even a home grown protocol
like I am/was working on, 1394 packets will be given timestamps for
presentation at the receiving end, and 1394 can transmit these packets in
full Jack data block sizes, or smaller to make more efficient use of 1394
bus bandwidth.
Just being clear that 1394 and this conversation _can_ _be_ completely
orthogonal. (And should be IMO)
Thanks,
Mark
-----Original Message-----
From: linux-audio-dev-admin(a)music.columbia.edu
[mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of Martijn
Sipkema
Sent: Wednesday, February 26, 2003 8:57 AM
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] Linux Alsa Audio over 1394 - a Thesis
[...]
Because I think ALSA does too much in the kernel (and it is not
well documented eiter).
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).
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. 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. 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