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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
