[GH-ISSUE #94] Initial volume appears to do nothing #64

New issue

Closed

opened 2026-02-28 14:25:05 +03:00 by kerem · 3 comments

kerem commented

2026-02-28 14:25:05 +03:00

Owner

Originally created by @Willyarma on GitHub (Sep 16, 2024).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/94

I was just experimenting with audio_device, mixer_device and mixer_control_name.
I had a hard time trying to figure out what names to put for these, but I figured it out in the end.

cheap USB audio device:

audio_device: plughw:3,0
mixer_device: default:3
mixer_control_name: Headphone

rpi4 built in output:

audio_device: plughw:0,0
mixer_device: default:0
mixer_control_name: PCM

However it appears that putting initial_volume: 100 (which is default anyway) in the config.yml doesn't change the volume at all.
I assumed its supposed to set max volume at startup, have I misunderstood this?

If I query the volume with a GET request to /player/volume, its coming back with whatever it was set to before, not 100, (so go-librespot doesn't think its a 100 when its not, i mean)

I was setting the volume to low with alsamixer and then starting up go-librespot to see if it went up again.

It not a huge problem for me because if I send a POST request to /player/volume with {"volume":100} in the body (stringified JSON) this works and I can just do this from my own program.

Originally created by @Willyarma on GitHub (Sep 16, 2024). Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/94 I was just experimenting with audio_device, mixer_device and mixer_control_name. I had a hard time trying to figure out what names to put for these, but I figured it out in the end. cheap USB audio device: audio_device: plughw:3,0 mixer_device: default:3 mixer_control_name: Headphone rpi4 built in output: audio_device: plughw:0,0 mixer_device: default:0 mixer_control_name: PCM However it appears that putting initial_volume: 100 (which is default anyway) in the config.yml doesn't change the volume at all. I assumed its supposed to set max volume at startup, have I misunderstood this? If I query the volume with a GET request to /player/volume, its coming back with whatever it was set to before, not 100, (so go-librespot doesn't think its a 100 when its not, i mean) I was setting the volume to low with alsamixer and then starting up go-librespot to see if it went up again. It not a huge problem for me because if I send a POST request to /player/volume with {"volume":100} in the body (stringified JSON) this works and I can just do this from my own program.

kerem

2026-02-28 14:25:05 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-28 14:25:05 +03:00

Author

Owner

@Willyarma commented on GitHub (Sep 16, 2024):

I noticed after that others have open similar tickets, sorry if I have created a duplicate or misunderstood something.
Looking at PR #51 it seems its by design that initial volume does nothing when a mixer if defined.

What I want is for the Alsa volume to be at full always as I want a fixed line output.
I guess I could do this using the amixer command myself.

What would be nice is a separate API endpoint or an extension to the existing /player/volume to separately set the mixer volume and have a separate configuration parameter for initial mixer volume. (Useful when external_volume is true)

@Willyarma commented on GitHub (Sep 16, 2024): I noticed after that others have open similar tickets, sorry if I have created a duplicate or misunderstood something. Looking at PR #51 it seems its by design that initial volume does nothing when a mixer if defined. What I want is for the Alsa volume to be at full always as I want a fixed line output. I guess I could do this using the amixer command myself. What would be nice is a separate API endpoint or an extension to the existing /player/volume to separately set the mixer volume and have a separate configuration parameter for initial mixer volume. (Useful when external_volume is true)

kerem commented

2026-02-28 14:25:05 +03:00

Author

Owner

@Willyarma commented on GitHub (Sep 17, 2024):

Just so its clearer to others, here are my findings:

If no mixer is configured in the config.yml then the volume control is done in software, there is no control over the hardware volume, initial_volume works in this case.

Defining a mixer stops initial_volume working but the app slider controls the mixer volume and vice versa.

external_volume: true totally stops all volume control working, but it does pass the slider position in the app through the websocket, which is really handy for controlling a seperate controllable audio amplifier / receiver.

@Willyarma commented on GitHub (Sep 17, 2024): Just so its clearer to others, here are my findings: If no mixer is configured in the config.yml then the volume control is done in software, there is no control over the hardware volume, initial_volume works in this case. Defining a mixer stops initial_volume working but the app slider controls the mixer volume and vice versa. external_volume: true totally stops all volume control working, but it does pass the slider position in the app through the websocket, which is really handy for controlling a seperate controllable audio amplifier / receiver.

kerem commented

2026-02-28 14:25:05 +03:00

Author

Owner

@devgianlu commented on GitHub (Oct 20, 2024):

@Willyarma What you are describing in the last post is correct. I don't see any bug in the initial_volume not affecting the ALSA mixer because it would be a bit strange if, for example, the daemon restarts and updates the volume for no reason. I'll make sure to add a note about this.

Regarding the API, I think go-librespot should not provide an endpoint for controlling the underlying audio backend directly as that can be done via other means.

@devgianlu commented on GitHub (Oct 20, 2024): @Willyarma What you are describing in the last post is correct. I don't see any bug in the `initial_volume` not affecting the ALSA mixer because it would be a bit strange if, for example, the daemon restarts and updates the volume for no reason. I'll make sure to add a note about this. Regarding the API, I think go-librespot should not provide an endpoint for controlling the underlying audio backend directly as that can be done via other means.