On Tuesday 28 July 2009 06:46:11 Tim wrote: > With everything set to pulseaudio, sound sharing worked (i.e. two, or > more, programs could generate sound at the same time). But as soon as > *anything* directly used ALSA (or another sound system), it wedged > everything else, and sometimes even itself. You get the same whether > one thing, or everything was set to use ALSA (or OSS, or whatever else). This is precisely the motivation for introducing pulseaudio in the first place (ok, aside from networking sound and other stuff it improves). ALSA is a common audio interface for all hardware drivers, so that the app doesn't need to know how to deal with every and any sound card specifically. But ALSA provides just that, an audio interface (and it does a great job) --- one app uses it, other stay in line waiting (or failing). It is the simple situation of "only one app can open a file as writeable" philosophy. So the main idea is to have a sound server (pulseaudio) which takes the role of talking to apps, mixing all the audio, and giving the result to ALSA for playback. So PA is the only app that talks to audio hardware (through ALSA), while all other apps should be configured to talk to PA. But if some app is misconfigured and tries to use audio hardware directly (through ALSA protocol), things break. The question is therefore similar to a race condition --- which app gets to access the soundcard *first*? If it is PA, all apps that use PA will work, and those that don't, won't. However, if it is a "bad" app, PA will fail, and take down all "good" apps with it. I'm not a developer, but my naive idea to resolve this is to hard-code ALSA to allow access *only* to pulseaudio, and every app that doesn't play well should be denied access to ALSA and bugzilla-ed. Possibly make it a configuration option to fall back to permissive way if the user really doesn't want pa. My 2c. Best, :-) Marko -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
