[pulseaudio-discuss] Working with PA and jack

Colin Guthrie gmane at colin.guthr.ie
Thu May 28 01:38:04 PDT 2009


'Twas brillig, and Patrick Shirkey at 28/05/09 06:31 did gyre and gimble:
> Thanks for the heads up. There is no desire to use an api that is not 
> going to be future proofed. Would you consider having a "pajackcontrol" 
> app that uses dbus to communicate with pa and provides the existing api 
> hooks to jack so that legacy jack and non dbus jack can still signal pa 
> to play nicely?

Providing backwards compatibility is one thing but if the pulse client 
library just decides to use DBUS rather than sockets, why should any 
client application care? I don't think there is any intended client API 
breakage. That wouldn't go down well!

Even if it were a problem, why go to the effort? I mean if you want to 
use "legacy" jack, then why not "legacy" PA too?

Free software is an ecosystem, it's all moves together. If you take a 
Neanderthal man and place him in a modern city, he'd be dead by 
lunchtime, probably after trying to tame the big, red metal Mammoth.

I don't expect to compile a modern distro with gcc 0.1. etc. etc.

> Alternately "pactl -jack on" , "pactl -jack off" might work just as well.

That assumes that jack wants all your audio devices. What if you have a 
crappy USB speakers that are find for general usage but rubbish for 
pro-audio. Jack wont want them. Pulse should still get to use them.

This is handled currently by the dbus device reservation spec.



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]




More information about the pulseaudio-discuss mailing list