On 16/08/07, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
If PulseAudio is installed a lot of audio applications *will*
break. PA provides compatibility with a couple of audio APIs, and it
is my declared intention to provide compatibility with existing APIs
as good as possible. However some APIs are notoriously difficult to
virtualize (OSS), others don't really fit on top of something that is
not a hardware device (ALSA, OSS), even others are often violated
brutally by many applications (ALSA), and others are just too broken
to be properly emulated in PA.
Broken as in isn't designed to be replaced by PA? :)
Due to all that our compatibility APIs are far from perfect.
They're
quite good (and probably hugely better than any previous effort) but
there are still a lot of applications where they are not good enough,
especially those which play some dirty, non-standard games with audio
devices. (i.e. require DMA/mmap working, use exotic fragment settings
and suchlike).
Why should every application be forced to use the fragment settings
(or anything else) that you think are appropriate for PA? Some
applications are actually designed to work with a sound card, and
particularly professional audio apps *need* as direct as possible an
interface to reduce latency. Perhaps you should look at extending or
interfacing to jack instead of trying to replace it.
If your application doesn't work with any of our compatibility
APIs,
please file a bug to us and we'll try to fix this in our compat
layers. Please do *not* file any bugs regarding adobe flash. We know
it doesn't work on PA. Flash is completely broken when it comes to
audio it we can neither support it through our ESD compat nor through
our ALSA compat. Due to the closed source nature of Flash we cannot go
and fix their code. I will eventually add some workarounds for
this. But it's low priority on my list, given the closed source nature
of Flash. Oh, and Flash is evil anyway. ;-)
Flash actually works extremely well since they released the latest
version, and works fine on my systems both at home and here at work.
Why slate it for not working with your sound system, which goes out of
its way to eliminate or replace the existing "standard" interfaces?
"It's a low priority" isn't much of an answer.
#!/bin/sh
if test -x /usr/bin/pasuspender ; then
exec /usr/bin/pasuspender /usr/bin/jack.real "$@"
else
exec /usr/bin/jack.real "$@"
fi
Please use pasuspender only in few cases, because PA is network
transparent and by using pasuspender you loose that (among other
things).
Don't forget to depend on pulseaudio-utils in your spec file if you
use this!
If you depend on the package, you shouldn't need the "if test -x ..."
up there! Plus, it would actually pull in the PA package even if you
actually want to *avoid* installing it if possible.
6. If you have an application that uses ALSA, please make sure that
it
doesn't hardcode ALSA driver names (i.e. something like "hw:0"), it
should use "default" instead, which is now being redirected to
"pulse", our plugin for libasound. Hardcoding ALSA device names
(besides "default") is a bug in your application anyway, so here
you have yet another reason to fix that!
This sucks. Why can't PA just work as a network-capable server without
trying to take over my desktop?
2. I hate sound servers, and all this Pulse crap!
Please go back and hide under your rock again! Thank you!
If I have a sound card that happily manages mixing multiple sound
streams without using dmix or a server, can I avoid having PA replace
it as the "default" device? Or will I have have to just remove it
completely? Will I have to use rpm --nodeps --erase?