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

[Mark Knecht]

;-) 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 at music.columbia.edu
> [mailto:linux-audio-dev-admin at music.columbia.edu]On Behalf Of Martijn
> Sipkema
> Sent: Wednesday, February 26, 2003 8:57 AM
> To: linux-audio-dev at music.columbia.edu
> Subject: Re: [linux-audio-dev] Linux Alsa Audio over 1394 - a Thesis
>
>
> [...]
> > >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
>
>
>
>
>
>