Is it possible to adjust length of stop/pause fade?

[lanfear]

Is it possible? If yes, what setting? If not, is it much work to add that as an option?

The default fade length is too long for my taste, it makes the player feel unresponsive. Winamp's default fade length of 333 ms is a perfect tradeoff in my opinion.

[lanfear]

I just thought of this again - sorry to bump, but I'm really curious. Is the length of that fade somehow adjustable?

It would make the listening experience a lot "snappier" if I could shorten it...

[Strife89]

More than likely you'll have to edit the source code. I, unfortunately, have yet to learn C (the language Rockbox is mostly written in), but I might be able to dig up something given enough time.

Hope someone who really knows what they're doing comes along.

[safetydan]

The fade length is currently not configurable. If you really want more responsive stopping, wouldn't you be better off just disabling fade on stop/pause?

Though if someone is motivated to make it configurable, the volume fading code is in gwps-common.c

[lanfear]

Big thanks for your replies guys!

The fade length is currently not configurable. If you really want more responsive stopping, wouldn't you be better off just disabling fade on stop/pause?

Ah, of course, that's what I've been doing and that's ok.

But a fade gives a smoother touch to the experience (the reason it got implemented, I'd think), like the background lighting fades on and off instead of just blinking on and off.

To my taste, the Rockbox default is too long, while the Winamp default is short and snappy at 333 ms - still filling its purpose perfectly.

Though if someone is motivated to make it configurable, the volume fading code is in gwps-common.c

I appreciate the fill-in! I have extremely basic coding skills, but some day...

[ryran]

This is actually something that I used to think about back in the day. I eventually just disabled it. Only recently started using it again, since I got a new player and it's the default setting. Was thinking about it again today (before I read this) for the first time in a while: how I like the fade, but find myself waiting too long to see if I've actually paused or stopped the music.

I've got some basic familiarity playing around with Rockbox's svn tree (patching, compiling, etc), but don't actually know C. Looking at the code, I don't see anything so simple as a #ms value. Darn.

[pondlife]

It would probably be simple to change the current "Fade On Pause/Stop" option to a "Fade Length On Pause/Stop" (0-2 seconds in 0.1 increments?).  Only problem would be that people would lose their existing setting, and go back to the default.

I'll knock this up if anyone would be interested (and nobody would object to it in SVN).  Or is this just being too picky and bloating?

pondlife

[linuxstb]

Reading through this thread, it seems that the request is really just to shorten the fade time, so why not simply just do that?

I agree with the comments that it's too long, which is why I disable it.

Or does anyone actually like the current delay?

[Llorean]

I think it's too long, but I'm not sure a single preset shortened one would be suitable for everyone. Surely there are some people who'd merely like to "soften" the sharp cutoff of an instant stop (0.1-0.2s) while others might want it to actually seem to fade away a little gradually.

I'd say 0.1s increments from 0s-0.5s or maybe 0s-1s make sense to me.

[yapper]

I too think the current fade is slightly on the long side.

On a related point, is there any reason (other than lack of code), why the same fade isn't used in situations like seek start/stop, and the resume after headphone insertion?

[Llorean]

Seek starting/stopping would probably just result in overall sluggish performance. If you're trying to narrow down to a specific point, having the fade interfere with several small seeks would probably drive you insane, and it really doesn't make sense anyway. A more worthy goal there is "audible seeking" which would negate this anyway.

It should probably happen on resuming after headphone insertion though.

[pondlife]

Having offered a configurable time, I've looked at the code and now think just a shorter fade would be fine ;-).

Actually, if I understand the code correctly, we currently wait silently for 0.1s before fading in, and handle both fade in and out as 30 steps with a 1 tick sleep on each step.  This should give a litle over 0.3s for a fade out and 0.4s for a fade in.

(I'm assuming 1 tick always one hundredth of a second; does it vary on different devices?)

pondlife

[lanfear]

Wow, I'm glad no-one else (!) likes the current fade length either.

Pondlife - A configurable time would've been awesome, but if you say it's too complicated/not worth the time, then a short fixed one is perfect. Around 0.3s should be great!

Fade on seek could be nice, but as Llorean says it could also be annoying with shorter seeks. It makes more sense in media players on computers, like in Winamp, where you can instantaneously jump (random access) to any part of the file by clicking.

But a really, really short fade on seek start/stop could be useful for removing/taming loud transients and clicks... what do you guys think?

[lanfear]

I'm curious - would the change mean a lot of work, or is it quick?

[GodEater]

Pondlife - A configurable time would've been awesome, but if you say it's too complicated/not worth the time, then a short fixed one is perfect. Around 0.3s should be great!

I think you've misread what pondlife said - the way I read it, he's saying 0.3s is how long it is *now*.