On Fri, 24.08.07 11:44, Bill Crawford (billcrawford1970@xxxxxxxxx) 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? :) Yes, you are completely right. So? > > 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 The idea is to do away with fragment settings entirely and instead exclusively use system timers to schedule audio IO. That way we would be able to use huge hw audio buffers (which is good to avoid drop-outs). Every app would be able to specify the minimum required wakeup intervals for pa. We'd then use the lowest wakeup rate required by all connected applications. That way we generate near to none interrupts when playing movies and music (which is good for power-saving) but can do "zero-latency" at the same time. Basically this allows us to scale the number of interrupts with what clients request. This is partially implemented now, but only works with recent kernels which support hrtimers. WIP. BTW:: This is the way MacOSX/CoreAudio does it. > 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. In the meantime we have pasuspender which allows all apps to access the audio devices directly without having pa interfere. Also, I just lowered the timeout in PA to close the audio device when idle to 1s, so basically, the audio devices are very quickly closed after the last app stopped accessing it through PA. Thus, in many cases pasuspender would not even be required, though I still would recommnd its use. Who says I want to replace jack? Some kind of better integration is on my list. But replace? no. at least not in the near feature. Also, I am sure that PA will expose better and more flexible audio latency than Jack when the no-fragments stuff mentioned above is available. > > 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. You apparently don't know Flash as well as you think. > > 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? PA is more than a "network-capable" server. Oh, and PA doesn't want to take over your desktop. The way the pulse plugin for libasound is packaged these days is that it activates itself only when installed. If it isn't installed you won't notice it. > > 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? I *love* constructive criticism like this and the friendly tone of your email! You're a bigger fan of ALSA than the ALSA maintainers themselves. You are aware that the upstream ALSA maintainer also maintains PA in suse? Wake up! You're always welcome to remove pa from your machine. All that has been changed is that is is made the default in new installs. Given that you are such a sound guru, I guess you are a package manager guru as well and know how to delete a package? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
