Subject: Re: [linux-audio-dev] Linux Alsa Audio over 1394 - a Thesis
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Wed Feb 26 2003 - 18:11:02 EET
>I agree. Events should be timestamped. But maybe that not the only reason.
>Certainly EASI has variable size callbacks because this is what some
>hardware delivers.
sure, but then ALSA does the same. the question is whether to export
this detail up to applications or not.
>> i feel that it should be the job of ALSA to handle period sizes. if it
>> doesn't do a good job, it should be fixed. if we ask for a wakeup
>> every time 1024 frames are available,
>
>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.
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
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.
>> 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?
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.
--p
This archive was generated by hypermail 2b28 : Wed Feb 26 2003 - 18:12:21 EET