cplay volume should not affect other apps

[andreasvc]

ideally:

• use one volume control, applied to all the cplay players
  • each time a new player is launched, set its volume to this level with pulse (match on executable filename of player)
• do not affect master volume by default (unless selected by user). Changing volume in cplay should not affect:
  • volume of a video call in google meet
  • movie played on raspberry pi (omxplayer)
  • etc.

This requires using pulse for volume; therefore related to #16

Might also require looking into OSS/ALSA usage of players; players should have their own volume control in pulse.

[xi]

I have also thought about this for some time. So here are some thought:

cplay just starts the actual players (e.g. mpv, mpg123, …), so AFAIU the volume of these player can be controlled in pulseaudio, but cplay does not exist as an entity there.

It would be nice if you could define a group (e.g. cplay-{random_id}) in pulseaudio and then assign subprocesses to that group so that they inherit the volume settings. Unfortunately I don't think such a feature exists. Maybe this wil be possible with pipewire.

When cplay finishes playing one file and then starts the next one, a new player process is started. I am not entirely sure how pulseaudio handles volume in that case. I did a little experimentation and it seems like it picks up the volume of the last finished process of that player (e.g. if I start mpv1 and mpv2, then set the volume for mpv1 to 50% and mpv2 to 60%, then stop mpv1 while mpv2 is still running, then start mpv3, it will have a volume of 50%).

That means that setting the volume on the player process can still have an impact on other processes of the same player.

Another option would be to use volume settings of the players themselves instead of pulseaudio. I know that mpv has a --volume parameter, as does play. If the goal is to avoid side effects this is probably the way to go. On the other hand, this would need to be implemented for each and every player backend, potentially with a pulseaudio fallback for players that do not support setting the volume. I also think that most players do not support setting the volume programmatically while playing, so the process would have to be restarted, resulting in a noticable break.

I personally believe that the downsides outweigh the benefits, at least given the information that I have gathered so far.

[andreasvc]

Thanks for the ideas and info.

I would definitely want to keep this implementation as simple as possible (though not simpler, which it currently is). I think controlling the player's volume through pulse is the way to go; player-specific volume settings is hard to implement for a long list of players (and I like the minimalism of the players handling a single format). That way the user can also control the same volume using regular pulse volume mixer (I use the graphical pavucontrol). The fact that pulse apparently remembers the previous volume if it's the same player, as you say, makes this even more straightforward.

Then again, my annoyances with my raspberry pi which might be completely unrelated to cplay (not sure). To watch a movie (omxplayer, through kodi / osmc), I need to turn the volume all the way up. When I get back to listening to music, I either remember to turn down the volume, or wake up the whole neighborhood ... And my current raspberry setup uses alsa without pulse; I might have to change that.