SqueezePlay.pm: correct regexp for fade_volume #910
Conversation
|
I am trying to implement something into Squeezelite where I need a Mute or Unmute value. I would use the volume therefore, since this is the only "volume/mute" value one can fetch: "0" is mute and "vol>0" is unmute. This volume shall then steer an CEC device. CEC is not able to "switch" volume by it's value rather than smoothling changing the volume OR set mute and unmute. Having a ramp of volume values steers the CEC device rather than promptly sending the mute command. Then I found that comment in the code "#SP does local audio control for mute/pause/unpause so don't do fade in/out". So I thought: This is exactly what I need, since Squeezelite usually should have no timers/alarms (as far as I understand). But: I did not get the behavior described in that comment... As far as I read that piece of code including the comment, I understand the following: EDIT: as far as I see is @philippe44's commit changing the behavior when there is a squeezelite, explicitly only letting the squeezeplay of fab4 and baby ignore the fade and excluding "all other squeezeplay" devices. So, referring to @philippe44's comment there should probably be an addition made like "!~/baby|fab4|squeezelite/". This would then allow that the "else" will hold for a squeezelite that has no alarm's, etc. Or is there any other clean option to stop that fade on mute??? |
|
If he added the condition to explicitly let squeezelite use the first conditional statement, then it's unlikely that adding squeezelite to the condition would be in his interest 😀. It's my understanding you try to deal with mute/unmute in the client, when that's handled on the server side for your client (squeezelite)? As you don't specify what exactly you want to implement in your squeezelite, it's hard for me to suggest whether this could be driven from the server. But changing the server for everybody to accommodate your particular need will be difficult. You could try to write a plugin overriding the above behavior though. |
Okay. I have to admit that I cannot neglect your point 😂 . He has his point, of course. It just seemed not quite obvious to me... Well, anyway. Sorry for that. I hope you still want try to help me.
Sorry as the text below is a little longerm but I hope to explain everything understandable. If you prefer I can also point you to latest code I wrote... I added the capability to squeezelite to steer a hardware device's power and volume via HDMI-CEC (using libcec & and a HDMI cable). Therefore, I set the volume control to a certain value and hand that over to the soundcard as a fixed "real/hearable" volume. Thus, the device always gets a fixed volume. The volume up/down/mute is then done by steering the amp via the CEC commands. Unfortunately, CEC only allows to do vol up/down by increments rather then setting a specific value. I got that implemented taking a volume value that was delivered to squeezelite via "audg" and then driving the "volume wheel" to the value I need. You can describe this behaviour like those old amp with the volume wheel rotating when you press the remote. So, everytime I get a volume value this mechanism starts, including this fade when muting. This mechanism is just slow by it's nature. For mute/unmute, there is no flag/option in slimproto. The only thing I can use is "0" for "muted" and ">0" for "unmuted volume". This works well in all clients that are out there, as they set the volume to a specific value, since they are as fast as the server. The mechanism I have to use is fading slower than the server and thus no real mute. I would need something like, "vol 0" when hitting mute on the gui. I get "vol 10, vol 7, vol 5, vol 3, vol 0" when muting. This is not distinguishable from a normal volume run. Disabling the fade delivers exactly the behavior I need (although it sends the stuff more than once) but I get the a "abrupt" volume change to zero (e.g 10 -> 0). Probably an addition to slimproto via a Plugin or whatever might also solve the problem. I thought of an additional flag in the "audg" packet like "mute=[0|1]", a new flag "audm" similar to "aude", a configurable "fade time" for the mute... For me a solution without a plugin seems the best option, because I think that the issue with the mute I have is something a greater user community could benefit from... Is there any advice you could give me? Maybe I start with a Plugin or so... Could you point me to a Plugin-scheme that could overwrite the fade_volume in SqueezePlay or another one that might "add to the protocol"??? |
|
The Squeezelite-ESP32 project uses a custom player class to override/extend some of the behavior, too. It's a good example to learn how you can extend your player's feature set:
You'd obviously have to register a different player class ID than the above, and you'd have to use the same in your squeezelite implementation. But that way you might be able to override |
|
Ah. Thanks a lot. Idea would be: hasPreamp is 1 then do not fade_volume... |
Hej there,
I am trying to get some proper Mute Info into Squeezelite and found something possibly wrong in Slim/Player/SqueezePlay.pm.
Shouldn't the regexp in that line: https://github.com/Logitech/slimserver/blob/a063401fe91bc81889f3ca2524f1ce6ab349879c/Slim/Player/SqueezePlay.pm#L250
rather be
... if (abs($fade) > 1 || $client->model =~ /baby|fab4/) { ...Otherwise the comment
# for long fades do standard behavior so that sleep/alarm workdoes not make any sense (at least) to me: squeezelite usually has no internal alarm function.
The issue would also explain why I am getting fade on mute and unmute with squeezelite...