Null mixer to skip volume control

[lautis]

Implement a null mixer that does not control volume with software. Having such mechanism is useful if you want to use some external method for volume control, but it isn't available in Librespot.

To support the null mixer, we'd most likely want to also expose volume changes as events that trigger external script.

[JohanGroenenboom]

Thanks for implementing this feature, it's a relevant use case, I need it as well. I implemented a fixed-volume setting but your solution is the better one.

[lautis]

Might be interesting to have option to disable volume control in your case also in the clients. But sounds very similar to my use case: I had the soft volume disabled and then synced volume to my amplifier separately as it has a TCP/IP API.

That said, as a workaround (or a better solution, depending on use case), you could create a null sink in PulseAudio and set that as a mixer for librespot. Then librespot controls the dummy mixer rather than the real sound device.
In /etc/pulse/default.pa:

load-module module-null-sink sink_name=null sink_properties=device.description="Null"

And then give librespot options --mixer-card null --mixer-name Master.

I believe similar functionality exists in ALSA, but I used Pulse as I could quickly figure out how to have a meaningful name for the null sink.

[JohanGroenenboom]

Thanks for your additional ideas. About disabling volume control in the clients - how could this be done when your client is the Spotify app?
My target device didn't have pulseaudio so far - one of the reasons for a null mixer for me is bit-perfect playback. I get the impression this would be harder to achieve with pulse than with direct alsa playback? Does your null-sink only defeat volume control, or does it waste the audio output samples alltogether?
I haven't been able to find a way to configure alsa in any way that bypasses volume control, I'm not sure that it's possible.

[lautis]

The additional pulse audio sink is there only to defeat volume control. I guess you could use any existing extra audio devices or in Alsa load dummy driver. Mixer card is separate from the audio device used for playback and no audio samples is going through the dummy device.

Regarding disabling volume control, I'm not sure either how that could be done. However, I know that when I'm playing on a phone, the official Spotify client does not allow me to change volume of the device. There must be a flag in the protocol to disable remote volume control.

[ashthespy]

Ah, I seem to have missed seeing this for some reason.
FWIW, following inspirations from @JohanGroenenboom's issue over at volumio/Volumio2#1771, I implemented something that gives similar functionality and also disables the UI volume control at the client side.
ashthespy@6e369f0

Regarding disabling volume control, I'm not sure either how that could be done. However, I know that when I'm playing on a phone, the official Spotify client does not allow me to change volume of the device. There must be a flag in the protocol to disable remote volume control.

This can be done by setting Capabilities::disable_volume to true - but that will need the Capabilities protobuf to be updated first.

A simpler solution that also seems to work is use the current protobuf format is to set kVolumeSteps to 0 instead.

[JohanGroenenboom]

@ashthespy - Trying to build your commit, I get these kinds of errors:
error[E0463]: can't find crate for futures
--> src/main.rs:2:1
|
2 | extern crate futures;
| ^^^^^^^^^^^^^^^^^^^^^ can't find crate

I'm still relatively new to rust projects, so I may be missing something obvious, if so can you give me a hint how to build? Or has something gone awry with dependencies.

[ashthespy]

@JohanGroenenboom that branch is setup to use a library, and not as a binary. You'd need to uncomment out the dependencies in Cargo.toml. Else, you can hop across the my Volumio specific vollibrespot daemon repo and grab a pre-compiled version from the currently open issue.