[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PulseAudio is now enabled by default on new Fedora installs



On Fri, 24.08.07 11:44, Bill Crawford (billcrawford1970 gmail com)
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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]