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

sure, but then ALSA does the same. the question is whether to export this detail up to applications or not. 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. 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