[pulseaudio-discuss] pulse client implementation

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Thu Mar 27 00:44:53 PDT 2014

On Wed, 2014-03-26 at 19:22 +0000, Pete Beardmore wrote:
> hi,
> 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

My recommendation would be to get rid of the setting in the
configuration file. Let pulseaudio take care of the routing.


More information about the pulseaudio-discuss mailing list