[pulseaudio-discuss] Working with PA and jack

Lennart Poettering lennart at poettering.net
Sat Jun 6 17:02:03 PDT 2009


On Thu, 28.05.09 09:38, Colin Guthrie (gmane at colin.guthr.ie) wrote:

>
> '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!

Actually, if we adopt RTP for data transfer we'll probably do that in
a way that is incompatible with the current API. One of the weaknesses
of the current protocol is that we shove control and audio data over
the same channel. When we go for RTP we will will have seperate,
independant channels for each stream of audio data. When we have that
we will probably not be able to make the same ordering guarantees of
the client requests we currently make.

But uh. The whole RTP+D-Bus story is nothing I'll be working  on any
time soon. I'd rather not talk too much about it right now.

Lennart

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



More information about the pulseaudio-discuss mailing list