Moving fading from the server to the squeezeboxitself

[cjk32]

kdf wrote:
> Quoting Christopher Key <cjk32 (AT) cam (DOT) ac.uk>:
>
>> Removal of all the server side fading code.
>
> This would then leave SB1 and Slimp3 users high and dry.
> While firmware development for those devices is effectively ended,
> support for them is still an immportant factor in slimserver
> development.
>

Fair point. Having to change the server behaviour for just SB2 and more
recent is a lot less attractive, and may well make syncing different types
of player a real nightmare. That said, it does seem somewhat silly to
restrict more recent hardware to a sub optimal solution for legacy reasons.

Chris

[kdf]

Quoting Christopher Key <cjk32 (AT) cam (DOT) ac.uk>:


> That said, it does seem somewhat silly to
> restrict more recent hardware to a sub optimal solution for legacy reasons.

I wouldn't ever susgest that. You cannot remove the fade from the
server, but you CAN rework the Squeezebox2 and Transporter modules to
not use it. for example, you could create a generic
Player::Player::fade_volume function which uses the existing routine.
Then have a Player::Player::Squeezebox2::fade_volume that calls a
SlimProto function to initiate the hardware fade.
-k

[cjk32]

kdf wrote:
> Quoting Christopher Key <cjk32 (AT) cam (DOT) ac.uk>:
>
>
>> That said, it does seem somewhat silly to
>> restrict more recent hardware to a sub optimal solution for legacy
>> reasons.
>
> I wouldn't ever susgest that. You cannot remove the fade from the
> server, but you CAN rework the Squeezebox2 and Transporter modules to
> not use it. for example, you could create a generic
> Player::Player::fade_volume function which uses the existing routine.
> Then have a Player::Player::Squeezebox2::fade_volume that calls a
> SlimProto function to initiate the hardware fade.

That would require minimal reworking of the server, allowing the same
algorithm to be used for synced players and so on. It's not ideal as it
doesn't guaruntee simultaneity of the fade finishing / starting and playback
ceasing / starting, but would certainly improve matters. Might it be
possible to go a bit further and add a generic pauseFade that does some of
the work currently in Slim::Player::Source, calling fade_volume for pre
SB2s. An SB2 / Transporter specific version of pauseFade would then send
strm commands to the squeezebox to control pausing and fading.

Chris

[cjk32]

dean blackketter wrote:
>
> If you haven't filed a bug with the details, please doo.
>

http://bugs.slimdevices.com/show_bug.cgi?id=3975