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 Pete
