When librespot is built with Avahi turned on, it will crash if Avahi is
later not available at runtime.
This change avoids it crashing hard when Avahi is not available;
librespot will merely warn of the issue.
This affects some distribution packages too, where the maintainer might
prefer leaving Avahi support enabled, but many setups don't (or can't)
run Avahi.
Co-authored-by: Nick Steel <nick@nsteel.co.uk>
This sets the name displayed by PulseAudio to Librespot - Instance Name if a name is given otherwise Librespot (the default name).
This also sets the correct "role" as per the docs:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/ApplicationProperties/
PA_PROP_MEDIA_ROLE
"This is a property of the actual streamed data, not so much the application"
Roles are used for policies, things like automatically muting a music player when a call comes in and whatnot.
For bonus points this also sets PULSE_PROP_application.icon_name to audio-x-generic so that we get a nice icon in the PulseAudio settings by our name instead of a missing icon placeholder.
This saves up to 1-2% CPU useage on a PI 4 depending on how much normalisation is actually being done.
* We don't need to test against EPSILON. The factor will never be over 1.0 in basic normalisation mode.
* Don't check the normalisation mode EVERY sample.
* Do as little math as possible by simplfiying all equations as much as possible (while still retaining the textbook equations in comments).
* Misc cleanup
* Update GStreamer backend to 0.18
* Don't manually go through all intermediate states when shutting down the GStreamer backend; that happens automatically
* Don't initialize GStreamer twice
* Use less stringly-typed API for configuring the appsrc
* Create our own main context instead of stealing the default one; if the application somewhere else uses the default main context this would otherwise fail in interesting ways
* Create GStreamer pipeline more explicitly instead of going via strings for everything
* Add an audioresample element before the sink in case the sink doesn't support the sample rate
* Remove unnecessary `as_bytes()` call
* Use a GStreamer bus sync handler instead of spawning a new thread with a mainloop; it's only used for printing errors or when the end of the stream is reached, which can also be done as well when synchronously handling messages.
* Change `expect()` calls to proper error returns wherever possible in GStreamer backend
* Store asynchronously reported error in GStreamer backend and return them on next write
* Update MSRV to 1.56
When there's a value that corresponds to an argument name used in the same command line, the logging of the arguments gets confused and logs the matching argument, but without the leading dash:
```
% target/debug/librespot -n c --verbose -c /path/to/my/cache
[2022-02-07T22:32:25Z INFO librespot] librespot 0.3.1 55ced49 (Built on 2022-02-07, Build ID: qaEB8kEW, Profile: debug)
[2022-02-07T22:32:25Z TRACE librespot] Command line argument(s):
[2022-02-07T22:32:25Z TRACE librespot] -n "c"
[2022-02-07T22:32:25Z TRACE librespot] c "/path/to/my/cache"
[2022-02-07T22:32:25Z TRACE librespot] --verbose
[2022-02-07T22:32:25Z TRACE librespot] -c "/path/to/my/cache"
```
Here we're using the literal `c` as the device name, and the `-c` argument. Thus the `c /path/to/my/cache` is logged in addition to `-c /path...`.
After checking whether the key has a leading dash, this issue is gone:
```
% target/debug/librespot -n c --verbose -c /path/to/my/cache
[2022-02-07T22:32:41Z INFO librespot] librespot 0.3.1 55ced49 (Built on 2022-02-07, Build ID: qaEB8kEW, Profile: debug)
[2022-02-07T22:32:41Z TRACE librespot] Command line argument(s):
[2022-02-07T22:32:41Z TRACE librespot] -n "c"
[2022-02-07T22:32:41Z TRACE librespot] --verbose
[2022-02-07T22:32:41Z TRACE librespot] -c "/path/to/my/cache"
```
