Quoting Max Kellermann <[email protected]>:
the same issue would occur if a sink set in the config was removed,
hence it's an existing issue
That's not a valid argument.
i respectfully disagree
..If the user tells MPD to use a specific
sink and then removes that sink, then MPD can't possibly fulfill the
user's wish. That's a user error, and we don't need a programmatic
solution for that.
again i disagree. it seems pretty fundamental too, so maybe we've just
got slightly different ideas/expectations of what pulseaudio support
entails for a client
pulseaudio, for me, is all about manipulating streams, like 'jack',
nothing is fixed, as it was in the days where alsa ruled the roost. to
'support' pulseaudio therefore means you support the following kind of
things as 'the norm':
-configure mpd for sinkA
-move mpd stream to sinkB
-remove sinkA
currently mpd refuses to play after the current song/stream has
finished. to me, that's useless
what is the user's wish here? you imply it is to play through sinkA
(and fail), as that's what they'd originally configured. i disagree.
i'd say, boldly, the user wishes 'to play music through sink B'
..because that's where they'd explicitly moved the last mpd stream to
the same argument goes for the scenario(s) which were the original
scope of this change e.g.
-configure mpd for sinkA
-move mpd stream to sinkB
-stop song
-start song
currently mpd will start playing again through sinkA ..but the user's
just made the effort to move the stream to sinkB. so again, to me,
that's useless
But if the user tells MPD to use a specific sink, and the next day
finds that MPD wants to connect to a very different sink that doesn't
exist anymore, different from the one he configured in mpd, he will be
disappointed and wondering what the hell MPD is doing.
i can't think how this would ever happen, unless you're
(unnecessarily) re-iterating what was happening in the original patch,
which was fixed immediately, and was stated so?
(post patch), the only reason mpd wouldn't play through the sink a
user originally configured, is if they'd gone out of their way to
manually move the stream (via various pa tools e.g. pactl,
pavucontrol). so they're not going to be totally lost/confused at all,
they moved the stream, it should be wherever they left it!
also now, if a sink disappears, mpd always copes, and although more as
a side-effect, if the user does erroneously configure the sink, mpd
again copes, with the log message:
pulse_output: sink playback failure, falling back to pa server sink selection
..hopefully enough to point the user to their mistake. why not help
the user out? why not support more than the bare minimum of use-cases?
primarily (post patch), what mpd would be doing, is playing nicely
with pa, respecting what the user has done to their mpd stream
This whole idea leaves me with a bad taste.
it really shouldn't. my elementary coding skills maybe, but not the
idea of improving pa support, coping with more use-cases
I still don't like the new version of the patch (even without this
"const" chaos), because it makes MPD lose information, and still leads
to a surprising situation. Not less surprising than before, not even
better, just a little bit different. The change is not an
improvement.
but by the time the changes take effect, the lost information is
useless, either invalid (sink doesn't exist) or erroneous (sink
moved), so why does it matter?
as far as surprising situations go, i think that a user who knows how
to move streams, and uses this functionality is certainly going to be
surprised, but at the current state of affairs (as i was). this change
is the single reason i joined the list and got involved, that's how
irritated i was by the current behaviour. all other issues i've worked
on have been purely to get mpd-git to a usable/working state for me to
implement this change
so, maybe it'd be nice to get some more opinions here, i'm possibly
suffering tunnel vision..
..is mpd doing the sensible thing already in these scenarios?
when is someone who moves streams going to be confused by my change?
please help me think of the use-cases where falling back to letting pa
control sink selection isn't useful ..again bearing in mind that what
triggers the behaviour (moving streams, dead sinks) is not going to
happen for the standard 'fix a sink and play' scenario
as the change is desirable in the above scenarios for users who move
streams, and doesn't affect those who don't, i really can't conclude
that it brings no improvement, especially without some concrete
use-cases which it either breaks or hinders
I believe you misunderstand the "const" here:
- const char *sink;
+ char* sink;
The "const" refers to the string data, not to the string pointer.
Note the difference between:
const char *foo;
char *const foo;
const char *const foo;
sorry, it was v1 of the patch which required manipulation of the
string data (hence the change to a string object). v2 needed nothing,
stupid mistake (fixed), but "const chaos", not really! always
appreciative of help from far superior coders though, so thanks for
the pointer here
_______________________________________________
mpd-devel mailing list
[email protected]
http://mailman.blarg.de/listinfo/mpd-devel
