On Thu, 23.04.09 15:36, Callum Lerwick (seg@xxxxxxxxxx) 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
