--- title: "Two-Person Offline Turn-Taking Music Player" date: "2026-09-15" canonical: "https://raytally.com/en/ideas/2026-09-15-idea-4a77ad69/" generator: "RayTally · dev-prompt-v4" signal: query: "Purpose-Built Portable Music Players: RHYTHM Is a From-Scratch Digital Audio Player" observed_at: "2026-09-15T00:33:04.381Z" sources: - url: "https://www.trendhunter.com/trends/digital-audio-player-trend" boundary: "Published at 2026-09-14T00:00:00.000Z. Observed at 2026-09-15T00:33:04.381Z." - url: "https://www.yankodesign.com/2026/09/12/rhythm-is-the-walkman-the-smartphone-era-forgot-to-build/" boundary: "Published at 2026-09-12T00:00:00.000Z." - url: "https://docs.espressif.com/projects/esp-adf/en/latest/design-guide/esp-audio.html" boundary: "No publication timestamp is present in the source record." - url: "https://support.spotify.com/us/article/jam/" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-09-15-idea-4a77ad69/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Two-Person Offline Turn-Taking Music Player For two people traveling offline, a pocket player alternates songs from their local libraries and sends synchronized playback to two headphones—without either person needing to pull out a phone. ## Product concept Before boarding a train, taking a long-haul flight, or heading out to camp, two people load the local music they want to share onto the same microSD card. The player recognizes the two libraries, lets each person choose a few must-play tracks, then alternates later selections by turn. Its small display shows only the current song, whose turn it is, and the number of shared favorites. The device supports two pairs of headphones, with separate volume for each listener. Either person can use a physical button to accept the current song, skip it, or add it to the trip’s shared playlist. There are no notifications, recommendation feeds, or online logins, and song choice does not favor whoever is holding a phone. At the end of the trip, both people export the playlist they agreed on, along with its play order. The first version supports common audio formats, dual-headphone output, and alternating playback from local libraries, without streaming aggregation. It is less a music player than a small travel object that lets two people take turns sharing their taste. ## Why now (backed by facts) Trend Hunter updated its RHYTHM coverage on September 14, 2026, and it was logged on September 15. Once dual independent headphone outputs and local playback are embodied in dedicated hardware, the question of who controls song choice on an offline trip becomes easier to see. ## Direction (model inference, not independently verified) Target user: Couples and friends traveling together by train, on long-haul flights, or while camping. Before leaving, both already have their own local music libraries but do not want to pass a phone back and forth all trip to choose songs. One person can easily end up controlling the queue while the other gradually stops sharing. The device turns the trip into a bounded exchange of musical taste and leaves behind a playlist both people approved. Minimal entry point: Build the hardware prototype around an ESP32-S3 for file parsing and a microSD card for local audio storage. Use ESP-ADF’s audio-player component for the initial playback layer. Validate only MP3, FLAC, and WAV in the first version, postponing additional formats. During scanning, use top-level directories to distinguish the two music libraries and create an index with source labels. Keep the queue state machine limited to must-play tracks, alternating fills, accept, skip, and shared favorites. Set volume independently for the two headphone outputs while keeping playback synchronized. At the end of a trip, write an M3U8 queue and a simple favorites list. The strongest case against: Dual headphone outputs add audio-circuit complexity, power draw, and debugging work. Differences in headphone impedance and sensitivity may make it hard to keep the listening experience consistent on both sides. Library scanning must also handle corrupted files, garbled metadata, and duplicate tracks. If button states are not clear enough, users may read a skip as a rejection of their taste. Rules for taking turns can also feel rigid when one person has a much smaller library. More practically, people can already make do with a headphone splitter or a shared queue. The product must prove that fair song selection and a lasting trip record justify another piece of hardware. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) Find early users in communities around digital audio players, Rockbox, local music libraries, and phone-free travel. Demo the full flow directly: two people insert cards, take turns pressing buttons, and export the playlist. Open-source the queue algorithm and enclosure files to encourage builders with soldering and 3D-printing skills to reproduce it. Before mass production, test small-batch assembly kits to learn whether people will pay for a two-person ritual or would rather download software. ## Competitors & gaps (model inference) - RHYTHM: RHYTHM already combines microSD storage, local lossless files, physical controls, and two independent headphone outputs in one device. Each output has its own amplifier, making it suitable for two people using different headphones. It addresses focused listening and a shared audio source, but the coverage does not show dual-library recognition, turn-based song selection, or shared reactions. Nor does it demonstrate must-play negotiation, selection turns, or trip-playlist export. A two-person offline turn-taking jukebox could follow its hardware direction while differentiating through the choices two people make together. The point is not another higher-fidelity player, but preventing the person holding the device from monopolizing song choice. If RHYTHM adds collaborative queues, this opening would narrow quickly. - Spotify Jam: Spotify Jam already lets multiple people join a shared session, add songs, view and reorder the queue, and pause or skip tracks. Participants can join by link, QR code, or nearby-device methods. The experience centers on Spotify accounts, phones, and a shared playback endpoint. Spotify’s official flow also says that in-app volume is generally controlled by the host. It is not designed to import and label ownership across two local microSD libraries, nor does it guarantee each person a turn to choose music. Its session setup also does not fit situations without a network connection or when people do not want to sign in. The offline device’s opening is a fixed pair, a defined trip, and dedicated physical controls. It trades breadth of choice for fairness, privacy, and a shared playlist worth keeping. ## How it makes money (model inference) Sell the hardware as a one-time purchase. The base kit includes the player, a charging cable, and a blank microSD card. A dual-headphone carrying case, spare batteries, and custom enclosures can be sold as accessories; there is no subscription. ## Source context Theme: Purpose-Built Portable Music Players Trigger Web Trend observation: Trend Hunter — Purpose-Built Portable Music Players: RHYTHM Is a From-Scratch Digital Audio Player This is one observation bounded by its publication and capture times. It is not evidence of market size or a broad trend and only explains “why now.” ## Sources - Purpose-Built Portable Music Players: RHYTHM Is a From-Scratch Digital Audio Player (https://www.trendhunter.com/trends/digital-audio-player-trend) - RHYTHM Is the Walkman the Smartphone Era Forgot to Build (https://www.yankodesign.com/2026/09/12/rhythm-is-the-walkman-the-smartphone-era-forgot-to-build/) - Audio Player — Audio Development Framework (https://docs.espressif.com/projects/esp-adf/en/latest/design-guide/esp-audio.html) - Start or join a Jam (https://support.spotify.com/us/article/jam/) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.