clients/playrtp.c: Replace the hairy interface-scanning heuristics. When we apply these heuristics, we already /have/ a known, working, connection to the server. So we can just use the address that the kernel gave us for our stream reception address. Replace the old hairy heuristics, and delete their support functions.
clients/playrtp.c, lib/configuration.[ch]: Static config for `playrtp'. The `disorder-playrtp' program already reads the client configuration. This change sets defaults for a number of parameters which could previously only be changed from the command line, which is a problem because `disorder-playrtp' is commonly invoked by Disobedience which doesn't allow one to set a command-line. These various tweaks are experimental, and may change, or even be removed, in some later version. The `rtp_request_address' and `rtp_always_request' options, in particular, might be replaced by some more complicated policy mechanism.
clients/playrtp.c: Fix the RTP-stream request syntax. Previously, the `-' syntax was an undocumented (and booby-trapped) way to inform the rest of the program that it should request a unicast stream. If we see this, then we apply some heuristics to select an interface to bind to, and ask the server to hurl packets at it. This is unsatisfactory. One might want to set a particular port, say because other ports are firewalled off by default. And one might want to set a particular address if the heuristics go wrong. As a first step, overhaul the command-line parser to accept an address and port name/number. We still apply the old heuristics if no address is provided explicitly, and we get the kernel to select a port number if none is given. This change is rather larger than I usually like, but there doesn't seem to be a useful intermediate state. Sorry.
Mark `help' and `version' functions as not returning. They don't; and later versions of GCC complain about potential `switch' fall-through mistakes without this. Fixing this is a simple matter of adding `attribute((noreturn))' in the right places. Note that `server/gstdecode.c' doesn't share the common attribute-macro machinery.
disobedience, playrtp: Have `playrtp' handle volume control. If the server is playing the audio directly, then it handles the volume control too, as before. If the server's transmitting using RTP, DisObedience /used/ to try to twiddle the volume itself. Instead, arrange for it to request volume adjustment of the running `disorder-playrtp' instance via its socket interface. This has two advantages. * Firstly, `disorder-playrtp' actually knows which audio API it's using and therefore which method for fiddling with the volume will work best. Indeed, DisObedience doesn't even have any configuration for selecting audio APIs, so it's only ever right by coincidence. On the other hand, `disorder-playrtp' has all of the necessary machinery. * Secondly, PulseAudio in particular has independent volume controls per input. DisObedience has no hope of guessing which of these is the right one for `disorder-playrtp' without help, and it's cleaner just to give the whole job to `disorder-playrtp'.
playrtp: refuse to play RTP via RTP. playrtp attempting to use the RTP backend becomes the default situation if no local sound output API is available. This can happen using (e.g.) Fink's GCC 4.4, because it cannot compile Apple's header files, and so concludes that CoreAudio/AudioHardware.h is not available. This is about the minimal possible change to stop playrtp crashing in this case. There are a variety of better possible answers.