3 hours ago
TL;DR:
A small, audio-first handheld released as an open dev platform, derived from PinePhone hardware, designed to be capable of a Rockbox port. Physical controls, great battery life, optional PineBuds + external display support. I would buy one immediately and actively work on the Rockbox port — I’ve been wanting an open hardware Rockbox target like this for a long time.
I wanted to float an idea that feels very aligned with Pine64’s strengths: reuse existing work, document it well, and let the community do interesting things with it.
Concept:
A single-purpose handheld primarily intended as a media player, but released explicitly as an open development platform, not a polished consumer product.
Think: “PinePhone without the phone.”
High-level hardware direction:
Rather than shipping with Rockbox, the goal would be to release a platform deliberately capable of supporting a Rockbox port, alongside other lightweight or experimental software.
Why this seems like a good Pine64 fit:
Personal note:
I would immediately buy this device and actively work on the Rockbox port. I’ve been wanting a modern, openly documented hardware platform suitable for Rockbox for some time, and this would be an ideal target.
Natural extensions (without diluting the focus):
The intent wouldn’t be another general-purpose Linux handheld, but:
an audio-first device released as a documented, hackable platform with a clear “this could run Rockbox” target many people already understand and want.
This feels like one of those rare ideas where most of the hard engineering is already solved, and the main challenge is restraint — choosing what not to include.
Curious what others think
A small, audio-first handheld released as an open dev platform, derived from PinePhone hardware, designed to be capable of a Rockbox port. Physical controls, great battery life, optional PineBuds + external display support. I would buy one immediately and actively work on the Rockbox port — I’ve been wanting an open hardware Rockbox target like this for a long time.
I wanted to float an idea that feels very aligned with Pine64’s strengths: reuse existing work, document it well, and let the community do interesting things with it.
Concept:
A single-purpose handheld primarily intended as a media player, but released explicitly as an open development platform, not a polished consumer product.
Think: “PinePhone without the phone.”
High-level hardware direction:
- Start from the PinePhone hardware lineage (SoC, audio path, power, USB-C)
- Remove phone-specific components (modem, cameras, etc.)
- Reduce overall size
- Add a small, low-power screen
- Physical controls (rocker / select / hold)
- Headphone jack, microSD
- Focus on battery life
Rather than shipping with Rockbox, the goal would be to release a platform deliberately capable of supporting a Rockbox port, alongside other lightweight or experimental software.
Why this seems like a good Pine64 fit:
- Rockbox already solves the hard problems for this class of device (audio quality, codecs, physical controls, power efficiency).
- Pine64 already excels at open ARM hardware where the value is documentation, reuse, and community ports
- There’s growing interest in calm, offline, single-purpose devices (especially for music) that don’t try to compete with phones.
Personal note:
I would immediately buy this device and actively work on the Rockbox port. I’ve been wanting a modern, openly documented hardware platform suitable for Rockbox for some time, and this would be an ideal target.
Natural extensions (without diluting the focus):
- PineBuds support for local playback and experimentation
- Modest mic + compute for on-device translation / transcription experiments (not positioned as an “AI gadget”)
- Optional external display support over USB-C for docking or experimentation, while remaining clearly a handheld media player first
The intent wouldn’t be another general-purpose Linux handheld, but:
an audio-first device released as a documented, hackable platform with a clear “this could run Rockbox” target many people already understand and want.
This feels like one of those rare ideas where most of the hard engineering is already solved, and the main challenge is restraint — choosing what not to include.
Curious what others think
