Keep custom audio speed setting during shutdown/reboot

[eugenkss]

I usually listen to podcasts with speeds like 1.25x or 1.5x
And I am happy that we can freely change the audio speed in Rockbox.

However, each time the player boots, the audio speed goes back to 1.00x
Is there any chance to include an option to make the audio speed persistent, so that a custom set audio speed is kept after the player is shut down and restarted the next time?
Like it is e.g. possible already for the sleep timer.

[johnb]

If you bookmark and stop your audiobook, the speed is part of the bookmark, IIRC, thus resumed afterwards.

[eugenkss]

Thank you.
Yes, I know. This is how I currently do it, in conjunction with "Bookmark on Poweroff".

But if the audio speed was persistent, you wouldn't have to execute a bookmark each time on bootup.
You could simply continue to play, instead of "Home, 3x Up, Right, Right" 

[Bilgus]

the pitch plugin pitch_screen.rock takes arguments

first go to settings>General Settings>Startup/Shutdown>Start Screen>Open Plugin

choose Viewers/pitch_screen.rock

now go to Apps/Open Plugins
under Start Screen you should see [pitch_screen.rock]
long press on the entry and choose 'Edit' from the context menu (choose No to browse)

EDIT After today:
choose Yes when asked to set parameter and No when asked to browse for a plugin

under parameter you can use these options

Code: [Select]

/* pitch_screen
 *  accepts args -q, -g, -p=, -s=, -k=; (= sign is optional)
 * -q silences output splash
 * -g runs the gui (DEFAULT)
 * -p100 would set pitch to 100%
 * -s=90 sets speed to 90% if timestrech is enabled
 * -k=true -k1 enables time stretch -k0 -kf-kn disables
so  '-q -p70 -s90' would hide the splash set pitch to 70% and speed to 90'

after saving it you can select the entry again and run it to see if it does what you want

now on startup the pitch will be set

PS. working on a patch to allow you to add a parameter for viewers without going to the plugin
 

[bahus]

There is an old patch available for this issue: https://www.rockbox.org/tracker/task/11619.

This patch is integrated into Poretsky's build (though it is not frequently updated): https://poretsky.github.io/rockbox/.

This plugin thing doesn't look to be very convenient for this scenario. You need to remember to set the pitch a second time via the Open Plugin every time you change it. And setting it up is not a straightforward process and requires more than just a few clicks.

[Bilgus]

we already have enough issues with nvram that I don't know that I want to add to it
that said the command line is already how it gets set
it'd be just as easy to save it to a cfg file when changed from within the plugin and I guess ask the user if they want it to persist between boots

[Bilgus]

other thing though how often are you wanting to save the pitch anyway esp through reboots?
I'm gonna file this under if not worth it there is the 5 click method they were using.

[rockbox_dev123]

... Poretsky's build (though it is not frequently updated): https://poretsky.github.io/rockbox/.

This looks interesting. The change list includes "an option to swap audio channels".

This would be nice for wearing IEMs cable down where L and R become reversed.

[bahus]

other thing though how often are you wanting to save the pitch anyway esp through reboots?

Quite often. My player frequently shuts down due to a timeout when I get distracted and leave it paused for 10+ minutes. When I return, I want to resume listening with all my settings intact. I usually set the pitch for audiobooks or reset it for music, so having to adjust it twice isn’t convenient. However, this is just my perspective on the scenario. The ability to provide parameters for plugins is definitely a useful feature.

[Bilgus]

if you have an actual use case for it we can implement most of the logic for it in the plugin spit out the .cfg file and make it run on startup if the file exists bypassing open_plugin completely to leave it open for other plugins

its sort of doing this already in the resume bookmarks case I think itd just be a case of checking for the .cfg file

[Bilgus]

what I don't want is every time you set the pitch it asks you to apply next restart or prompting to apply at boot when its been set

I'm thinking more of a second menu item like 'set global pitch' or 'pitch persist' and it then stores and applies that at boot

then you could still set an individual track and if bookmarked w/e itd get its own pitch and otherwise set the persistent one
Idk i'll have a look this next day or two

[Frankenpod]

Does the fixed.cfg file not have any use for this?
(I can't remember off-hand what attributes can be defined in that)

[Bilgus]

Well what I settled on was making the setting always persist and giving the user a option of "Pitch Reset"
it doesn't re apply the previous speed if you resume a track with different settings but I think that'll be ok
as it'd resume to the previous next boot unless you changed it again


still needs testing

https://gerrit.rockbox.org/r/c/rockbox/+/6344

[bahus]

> and giving the user a option of "Pitch Reset"

There is an action in Pitch screen for this. For me Pitch reset is mapped on long select (don't remember if I mapped it this way or it's default mapping). So separate setting for this looks redundant.

Just curious why you think NVRAM approach is problematic (I personally use custom build with NVRAM setting and I don't see issues with it).

[Bilgus]

the reset is important otherwise you'll get a user stuck in pitch and unable to figure out how to change it
I think I might make it blank if the pitch is normal but I'm not sure I can without trouble

There is an action in Pitch screen for this

plus that reset requires running the plugin

Its either that or you get asked to set next boot or asked at boot to reset, or you have a setting to find in the plugin
or a setting in the playback menus
I'm not doing the latter in fact I'd like to get rid of half the current settings due to the massive bin size for them

All of those have some downside to (someone)

Edit:
Nvram is emulated on most ALL targets so its not buying you anything except an opaque (non plaintext) way to write numbers to the disk but causes crashes when it gets corrupted or out of sync and who knows about the one device that actually has real NVRAM
we now have no devices using real NVRAM (requires HAVE_RTC_RAM) it was one of the SW HW codec targets I'm guessing

Pitch reset is mapped on long select

for you yes but what about the other 30+ devices
and less savvy users?