[pulseaudio-discuss] pulse client implementation

Pete Beardmore pete.beardmore at msn.com
Wed Mar 26 12:22:50 PDT 2014


i recently submitted a patch to an audio application which fixed what  
i saw as a failure to DTRT wrt its pulse implementation

specifically, the scenario whereby a user has explicitly configured  
the app (via config file - read on initialisation) to use 'sinkX', and  
then at some point during their 'session' (by which i mean 'time up  
until the binary is killed'), has moved the app's current stream to an  
alternative sink, 'sinkY'. finally, playback is stopped and restarted

the question is, which sink should be used for the new playback stream?

the two takes on this were:
1. the user explicitly specified 'sinkX' in the configuration, so  
that's where it should play next
2. the user explicitly moved the playback to 'sinkY', so that's where  
it should play next

another way of looking at this scenario is: 'if the user takes control  
of the app's stream (by moving it), should the app fall back to the  
default (passing NULL on connection) and let the pulse server control  
stream/sink placement, or should the app honour where the  
configuration file originally places it?

the disagreement was such, that it was suggested the only way forward  
would be to ask the pulse devs for their opinions. i appreciate this  
isn't a pulseaudio problem, so thanks for any input


More information about the pulseaudio-discuss mailing list