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
