Paul Davis wrote: > > >So what you are saying is "if we get everyone to switch to alsa and use > >alsa properly, (i.e. writing apps which send buffered audio data to the > >alsa-server in a timely fashion)" the need for a separate sound daemon > >will disappear. Right? > > Almost. > > "if we get everyone to switch to alsa, then everyone can share audio > interfaces". > > "if we teach everyone how to use LD_PRELOAD and they accept it, then > everyone can share audio interfaces without even switching to ALSA."
LD_PRELOAD on a casual basis is evil. It isn't needed if the system has the relevant libraries a the first choice in linker path anyway, so casual use of LD_PRELOAD on different applications is just a hack that can be dangerous to machine survival. LD_PRELOAD is not something to hand off to average users; even developers should beware of what happens when it is used wrong, as well as security problems. D. Stimits, [EMAIL PROTECTED] > > "if we get everyone to switch to alsa, and they use the poll interface > via ALSA to control their workflow, and/or only read/write avail_min > chunks of data, then they'll be ready for their app to work in a > synchronous execution system, of which JACK is an example." > > Just to keeps things complex, note that there is to stop a JACK server > from accessing a shared ALSA interface - remember, there is nothing > different in ALSA-using code whether its using a "hw" PCM device, a > "plug" PCM device, or a "multi" (subset) PCM device, or a "shared" PCM > device. the API is identical for all of them. > > --p
