[pulseaudio-discuss] pulse client implementation

[Tanu Kaskinen]

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.

-- 
Tanu