On Wed, Feb 25, 2004 at 09:17:54AM -0500, Paul Davis wrote: > There are only 2 differences associated with running the code you are > talking about in the kernel: > > a) it runs deterministically in interrupt context > b) it avoids a context switch back into user space It could be more optimized too.
> Linux is designed to make the context switch code very, very fast - if > it wasn't, then a system like JACK just could not work because it too > relies on context switches to make things happen. Next userspace daemon, then alsa-oss lib which could be swapped too. > The linux kernel community has long seen the kernel as a place to > avoid putting any functionality that can be provided in user > space. And the evidence is there that it *can* be provided in user > space. Of course we could done device drivers in userspace too ;-)). alsa-oss is some kind of virtual device, isn't it? Maybe we need to change to microkernel approach?? > drivers). When this happens, it becomes apparent just how non-realtime > friendly most application designs are. Yes that's true. So some kernel support for time critical apps should appear - not quite RT. > You can see exactly the same thing on Windows, where the MME model for > audio programming tends to produce programs that click and pop, > whereas those designed around ASIO and similar APIs do not (until > there is no alternative). Agree. > sigh. of course! because the kernel has no idea that your audio > application needs to run with real-time priority, and is instead > treating all apps as if they are normal interactive programs. if you > tell the kernel that your app needs to run with RT priority (there are So why I think about some api to tell the kernel that some app nedds CPU in more deterministic manner. Generally if we could do this by /proc too like tunnig ALSA for particular programs it would be good for old proprietary programs which we couldn't improve. It's not RT but some sheduler modification to treat some programs specially. > OSS cannot affect this in any way - its a function of the kernel > scheduler and not the audio device API. OK but we could have some kernel RT thread which is doing mixing or MIDI emulation. Regards -- Adam Tla/lka mailto:[EMAIL PROTECTED] ^v^ ^v^ ^v^ System & Network Administration Group ~~~~~~ Computer Center, Gdansk University of Technology, Poland PGP public key: finger [EMAIL PROTECTED] ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
