How long are the boot times with you? With me about 2 minutes from the power button to play until the first track. This really takes too long. May be due to the USB stick. But is there any way to send Volumio to standby? As with Windows, no big power consumption. And if I push the power button again, the system should be active in 10 seconds at the latest.
I need that for the kitchen radio. If my wife presses on it, is usually pressed several times, because everyone thinks it does not work. 
Hello, I am using volumio on an intel nuc on SSD for a while which like every x86 machine has suspend and hibernate states. So I am very interested to have this implemented in feature versions because I am not keeping it running 24/7 and yes boot time is quite long. I know this is normal for every OS but in the end it is in competition with other Hifi devices not with PCs. Wake up from suspend mode would be a nice feature. Really nice would be an option like on a windows machine where you can define how the OS acts by pushing the power button.
This seems to be a valid request, I never came round to implementing these kind of runtime features.
There are a few more of these x86 configuration features, like configuring the HDMI interface (as the touchscreen device does for sime cases), e.g. max. screen resolution to avoid too small fonts/icons on 4k/8k TV monitors).
It cannot be part of the default image, it would need quite a bit of development of an x86-specific plugin by a community developer with x86 and node.js skills as I doubt this will ever be high priority enough for the core team to realize this.
Expanding on @gkkpch response:
Suspend/Hibernate Support in Volumio: Context and Considerations
Thanks for raising the topic of suspend and hibernate support in Volumio — especially as it relates to x86-based devices like Intel NUCs. It’s a valid request and one that has come up periodically in the community. While the idea of faster resume times is attractive, especially for use cases like kitchen radios or family-friendly setups, there are some key reasons why this feature isn’t currently supported in official Volumio releases.
1. Volumio’s Unified Architecture Across Platforms
Volumio is built as a set of OS images that work across a broad spectrum of hardware, including low-power ARM boards (like Raspberry Pi and Tinker Board) and x86 PCs (like Intel NUCs and mini PCs). This unified design ensures consistency in feature support, plugin behavior, and maintenance across platforms.
Supporting suspend-to-RAM or hibernate would likely require significant platform-specific divergence — particularly for x86. This would not only increase the maintenance burden but also fragment the experience, which Volumio has historically aimed to avoid.
2. Challenges with Online Music Services
Many Volumio users rely on services like Spotify, TIDAL, and Qobuz, which use access tokens and session-based authentication. During suspend or hibernate:
- These tokens may expire or become invalid.
- Plugins may lose connection state, requiring full reauthentication.
- Background services like
spopd(for Spotify) or the Volumio REST API may not recover automatically.
At present, Volumio plugins do not have lifecycle hooks to detect resume events, which means there is no structured way to recover gracefully after suspend. This can lead to streaming playback failures or apparent freezes after wake-up.
3. Issues with Network-Dependent Sources
In addition to online services, many users mount NAS shares via SMB or NFS, or rely on UPnP/DLNA streaming. Suspend interrupts these network services:
- Network interfaces are temporarily shut down.
- Mount points can become stale or unresponsive.
- Network-based media servers may drop the connection.
Recovering from this requires either a complete remount of shares or a restart of discovery services, neither of which are currently automated in Volumio.
4. Local Playback May Work, With Caveats
If your use case involves only locally stored music (e.g. on an internal SSD or USB stick), suspend-to-disk can technically work — but some manual tuning may still be required:
- Audio subsystems (ALSA or bluez-alsa) may need to be reinitialized.
- Touchscreen or HDMI displays might not resume properly without configuration.
- Playback state is not preserved across suspend, so you may need to manually resume your last track.
5. What Would Be Needed to Support This
To properly support suspend/resume on x86, several things would be required:
- A plugin or service that hooks into
systemd’ssuspend.targetandresume.target - Logic to reinitialize plugins, network shares, and UI state on resume
- Lifecycle management support for online streaming plugins
At this time, Volumio does not include such infrastructure. While it could be developed, it would need to be done as a dedicated x86-specific plugin, maintained by the community, as the core team’s focus remains on features that work uniformly across all devices.
6. Community Development Potential
This doesn’t mean the idea is off the table. If you’re a developer interested in building such functionality — or willing to collaborate — the Volumio platform supports plugin development in Node.js and system-level scripting. Relevant areas to explore include:
systemdsleep targets- Custom Volumio plugin hooks (Plugin docs on GitHub)
- Community plugin examples such as volumio-plugins
Summary
Suspend-to-disk or fast resume is certainly a useful feature for x86 users with SSD-based systems, especially in a kitchen or casual environment. However, because of Volumio’s cross-platform architecture and the complexities involved with maintaining online service state, it isn’t something that can be easily added to the core build without breaking compatibility for other users.
That said, it’s a promising idea for community development, and if implemented cleanly as a plugin, it could offer a nice quality-of-life improvement for advanced x86 users.
Kind Regards,