[...] > >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
