On November 25, 2002 10:19 pm, Paul Davis wrote: > 2 clarifications: > >It is not logical for every program to write support for esd, artsd, jack, > >alsa, etc. Programs should write to ALSA and let ALSA do software mixing > > if required. Windows provided this since DirectX (3?). Solaris provides > > this too (esd apparently doesn't block on Solaris). > > Windows provides this, true. But most "prosumer" and professional > applications do *not* use it. The Windows kernel mixer was the curse > of pro-ish apps for a long time, hence driver models like ASIO and now > WDM. AFAIK, the new WDM drivers are generally used by apps in ways > that preclude "sharing" with other apps, and certainly ASIO drivers > cannot be shared in this way.
For "prosumer" and professional applications, lock it and block it. I have no idea how bad it is for miscellaneous simultaneous use of the sound device wrt interfering with these types of apps. But, if it is a problem - and I believe you that it is - then lock away. I don't think anyone would mind that. I don't think it interferes with what people would use smix for. > >One of the big reasons this is affecting me is that Java sound will not > > work unless you have a hardware mixer. My understanding is that the Sun > > folks seem to think that it is wrong to have to implement many different > > ways to create sound when the sound library (ALSA) should do it for them > > - the way it works in Windows/Solaris. I completely agree with them. > > ALSA is *a* sound library. There are lots of things that it doesn't > contain, and its written around a fairly specific programming > paradigm. There are those of us (many people on LAD) who believe that > its too hard to fit a callback-driven model into the existing ALSA > design, and that its therefore better to implement such a model > outside of ALSA. > > You see, if all apps are written to use the ALSA API, that's going to > be great for the purposes you have in mind, but totally awful for > those of us who want our audio apps to work in a sample synchronous > way and ignorant of the ultimate routing of their data. Many of us > don't think that an API based on the open/close/read/write paradigm is > appropriate for real time streaming media. If there was a way to temporarily disable the smix plugin, or temporarily gain exclusive ownership of the sound device for your purposes would that meet 100% of your requirements? > All that being said, I'd love to see the smix plugin implemented and > available, if only because it would allow ALSA native apps to > participate in a JACK system, albeit without sample synchronous > behaviour. Great. Know where to find it? :-) Even totally broken code that does not compile or do anything useful would be a wonderful head-start relative to starting from scratch. Cheers. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ ------------------------------------------------------- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
