On 16/08/07, Lennart Poettering <mzerqung@xxxxxxxxxxx> 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? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
