PulseAudio and sound apps (was: Re: Orphaning a few packages)

Lennart Poettering mzerqung at 0pointer.de
Thu Apr 23 21:01:20 UTC 2009


On Thu, 23.04.09 15:36, Callum Lerwick (seg at haxxed.com) wrote:

> > That solution (Jack on top of PA) does not work not because of mmap
> > access requirements of Jack. It does not work because Jack and PA are
> > _conceptually_ different and cater to different segments of the audio
> > users of Fedora and other distros. 
> > 
> > Jack is designed for very very low latency. Jack needs access to the
> > hardware devices. It cannot and should not run on "top of something
> > else". The requirement is not capricious. It is designed that way, and
> > works very well. Please don't break it. 
> 
> +1
> 
> The thing to do route Pulseaudio through Jack. Pulseaudio already has a
> Jack plugin.

As I already pointed out there is no point in running PA and JACK on
top of each other. Certainly not JACK on top of PA and not the other
way either.

PA and JACK have different purposes. For pro audio PA needs to go out
of the way and that's what it does with the device reservation
logic. 

The Jack plugin for PA is more a toy for exotic uses. It is nothing to
enable by default. Running PA on JACK is simply pointless, there is
simply no reason why you'd want that. You don't want to have event
sounds mixed in your pro audio stream, you don't want ekiga audio in
it, and you don't want flash sounds or rhythmbox or totem streams
it. The whole discussion of something like this is just complete and
utter nonsense.

So, no, "the thing" is NOT "to route PA through Jack". The thing is to
not have them interfere with each other and cooperate. And that's what
has been implemented now.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4




More information about the fedora-devel-list mailing list