Are separate display devices associated with headless endpoints a thing, and if not, can they be?

I’ve been enjoying using Roon to drive my existing Slimdevices Transporter networked players, but since Roon doesn’t send track info the Transporters’ displays it’s been making me feel a bit as if I’ve gone blind. I really like being able to see track info always displayed over there near the stereo where the music is coming from.

I completely understand why the Roon devs haven’t supported display on the Transporter - that device is based on the old Slim architecture where text rendering is apparently actually done server-side and pushed to the Transporter’s dumb display, and supporting it would be a whole bunch of effort added to the Slim-protocol side project which Roon folk have been kind enough to undertake even though it’s a distraction from the main project of supporting Roon’s native protocol. Roon does support displaying track info on the Squeezebox Touch (a newer-generation device which renders its own text).

But I’m not asking here for further work on Squeezebox-family devices or their protocol. I’m hoping for a class of standalone, linkable track displays which work within the native Roon protocol.

Looking into possible replacement endpoints which support Roon natively, a number of the better-regarded ones lack displays - a particularly intriguing example being the new Sonore microRendu. It actually seems appropriate to me that a device optimized for pure sound quality should not have a display or any of a display’s support circuitry inside, nor should it be taking on any of the computational tasks associated with running a display.

But… I really want a display. An audio-appliance-style display, reasonably big, which just shows track title and artist. Maybe elapsed and total time. Album art would be okay, but I actually don’t even care about that. A full complicated Roon user interface would be not only unnecessary but undesirable. It’d be sweet if you could also point a remote control at it and have it do basic control things (stop / pause / play / skip, maybe more) to the zone its associated endpoint was playing in. Because I don’t want to always have to unlock and swipe and stare at a tablet thing while engaged in music listening and life. And I know I won’t be filling the house with multiple computer lashups imitating the Sooloos/Meridian “Control-” devices of yore.

That “associated endpoint” thing is part of what I wonder if there’s protocol support for - because as I envision this, this sort of separate display would only be truly useful if it could be configured to always reflect whatever was going on on a chosen single hardware endpoint - presumably the one it would be placed in the same room as - regardless of what zones that endpoint got grouped into and out of.

This way, functionally it’d be as if the display and endpoint were part of the same device, but they could be shopped for and bought and situated separately. If this sort of device is a practical thing from the Roon native protocol standpoint, I can hope that a market might spring up in such displays. I’d buy four or more.

5 Likes

Buy a second-hand large Phone or Tablet for perhaps $100 or less

Run the Roon app on the device and have it display the “Now Playing” screen for the Zone in question

Position the Device near where your Transporter currently is… Or even better if it was closer to you…and perhaps use a docking station for power, as well keeping the display in an upright readable position

And this will act just like the Transporter display showing you what’s playing etc, etc

Yeah a cheap tablet on a small stand with the Roon App running would work great for this.

I bought a 11.75" remix ultra tablet for €250 (no vat no duties this time)

I second that request. But apparently not much interest. In particular, I’d love to add touchscreens to my RPi bridges.

I also second @Jeffrey_Moore request.

I don’t think large phone or tablet are adequate for this usage.

[quote=“volpone, post:6, topic:10381”]
I don’t think large phone or tablet are adequate for this usage.
[/quote]how so, what’s a tablet not do?

It’s mostly not so much what a tablet does not do, as what a tablet does not not do.

To wit: a full Roon interface on a tablet is unnecessarily complicated and featureful, and by that token less useful, in this context. I’ll expand on this in a separate followup later.

I think that most people replying to this feature request thread (by pointing out that I could just prop a tablet running Roon up somewhere in the room and be done) have completely missed the point of what I’m looking for, and that may well be because our expectations of how things should be done are often informed by the ways we’ve gotten used to doing them. Perhaps those people have a history wherein the only way they’ve routinely played music from a digital collection was via a computer or tablet/phone app interface.

The full Roon interface is the best thing I’ve ever worked with for helping me find the music I’m looking for - or the music I didn’t know I was looking for - or the music I need to hear even though I’d either forgotten about it or never known about it. The way available tracks and albums and artists are woven together in a web of text and links has made me a huge fan of Roon.

BUT. But. Having spent thirteen years living with Squeezeboxes of various generations as basic life infrastructure in most rooms of the house, I’ve really come to miss their strength as a simple, straightforward audio appliance.

They’d sit in among the components of each room’s stereo lashup, a simple box like a CD player, and they’d always show the track name and artist for what was playing. Because they only showed that information, that info was displayed large enough that it could easily be seen across the room, and it was displayed without unnecessary extraneous information or visual clutter. We got used to being able to glance toward the stereo at any moment and see what was playing. Guests got used to the same thing. We got used to being able to point a remote control at that box to pause the music (if a phone call came in or a discussion needed not to be interrupted), or to skip to the next track if someone was excessively annoyed by what was playing.

Since right now we’re still using our faithful Squeezebox devices, except as Roon endpoints - and because when the Roon developers added Squeezebox support they kindly did support relaying remote-control commands back to the Core - part of our accustomed functionality still remains, but if I migrate to dedicated headless RoonReady devices like maybe the microRendu, we’ll go from blind to blind and ineffectual. Because the interface friction of picking up a remote and hitting the pause button is much less than that involved in picking up a tablet or phone, turning it on and unlocking it, switching to the Roon app, and… doing whatever. This seems trivial, but in practice actually isn’t. There’s the delay of performing all these operations, and there’s the way picking up the phone/tablet takes you out of the social space of existing in the room and puts you in that exclusionary private space of staring into the mobile device. I want to spend less, not more, time in that phone-staring posture.

Often the detailed view the full Roon interface presents me with is exactly what I’m looking for, and it helps me follow links to the next piece of music I want to find and add to the queue or playlist I’m crafting. It’s absolutely my favorite interface for putting together the list of things to play, or finding that perfectly apposite thing to play next. It’s way, way better than either of the SlimServer interfaces (player or web page) for that.

Sometimes, though, all that detail and available deep interaction is just a distraction from the simple pursuit of listening to music. I want it all - the full Roon interface exists and I treasure it, but I’d also like to be able to treat a Roon endpoint as a simple audio appliance.

To take the parallel example of how writers work - sometimes you want to use your computer, which is an all-in-one encyclopedia, newspaper, stock ticker, shared scrapbook, party line, text editor and typesetter; sometimes (just as some writers are embracing a purposely dumbed-down modern reinterpretation of the primitive word processors of the 1980s to get away from the temptations and distractions of a general-purpose computer) you want an appliance.

So the appliance I fantasize about having, to restore Squeezebox-like appliancehood to a full Roon setup where the chosen endpoints are dedicated for audio and have no displays or remote controls, would:

  • Be capable of associating itself with one particular physical endpoint, regardless of what play groups that endpoint got moved in and out of

  • Display just current track info (track name, artist; more sophisticated configurability optional) and two or more of elapsed/remaining/total track time. I don’t particularly care if album art is shown, although some might.

  • Have (or be capable of having) an always-on display

  • Be capable of receiving simple navigation commands (at a minimum, pause / play / next track / skip to beginning of this track) from a remote control, and applying those controls to whatever play group the associated endpoint is in

  • Be capable of being wall-powered (I see no need at all for a battery)

  • Have an RJ45 for a wired network interface. I like for permanent infrastructure to be wired, rather than depend on WiFi. Other users may prefer WiFi, so including a WiFi interface (as long as its radio can be turned completely off for those of us who prefer not to use it and prefer not to bathe the audio equipment in extra RF) is optional.

  • Be designed to stand on its own, stably, with the display facing out into the room - it shouldn’t be anything purely flat which needs to be leaned against something.

Physically, it could look like a Squeezebox Touch or a Squeezebox 3 (except it’d need zero support for actual playing of audio, and it wouldn’t need a touchscreen) - or the designer could go in another direction (bigger, wider display, several side-by-side displays?) The sky’s the limit.

I know there exist all-in-one players with screens. That’s nice - but I now like the idea that the audio player could be designed and shopped for purely for its sonic prowess, the display / appliance UI portion could be shopped for separately, and it would all work together as a lovely composite device.

If someone made a good example of the device described above, I’d buy at least three or four.

But Roon proper isn’t a hardware company - so what I’m asking is if there’s protocol support such that the device I describe could be made. If there is, the next step is merely for someone to make it!

8 Likes

As we know, Squeezeboxes are no more as Logitech couldn’t make a sustainable business model out of them

So with that in mind, can you put a Price point on the device you have in mind above…one that will make it sustainable for Company X who decides to design, develop and market such a Display…and also a price point that will make it attractive to the type of music listener that you think this Display will appeal to??

Great post @Jeffrey_Moore. You make make an excellent point on how the inclusion of RAAT/other network devices has brought about use cases for Roon that are apart normal PC or tablet use and how interacting with these devices can impact social dynamics.

I too would love to have such a device and wonder if what you want could be accomplished via a raspberry pi + other parts. I think i recall one of the roon gents saying that RAAT would transmit the now playing info but i can’t see to find a post confirming it. If that is the case then it seems that a raspberry pi + a nice case with LED would do the trick. not an off the self solution but one that would certainly seem to be a drop in replacement solution for squeezeboxes and affordable.

Ideally i would love to add an LED screen to my Raspberry Pi running roon bridge that had displayed the top part of the queue screen.

3 Likes

Well… as we know, Squeezeboxes were a successful product under the original team who developed them; later, the line lost its way under Logitech, a commodity-hardware vendor. There may well have been a mismatch between company philosophy and audience after the line was gobbled up.

A number of people in this Roon community, though, come from the Meridian world where commodity pricing isn’t an absolute requirement.

I know nothing about estimating development, manufacturing and other associated costs.

I also don’t really know what others might pay.

I’d happily pay $200 each for well-executed devices as I describe; I’d less-happily pay $300 or more.

But also, as @AgDev01 suggests above, some of us might be able to bang together something which suits some part of the purpose from a little hobbyist computer like a Pi… which is why, while I was describing the device I’d love to have, I made it clear that my most immediate question was whether this functionality (particularly a separate device following the activity of a particular other audio endpoint - a single endpoint, regardless of its varying synchronization group affiliations) is possible given the current Roon protocol definitions. Because if it is, then it would make sense to try to get sample code from Roon and prototype something.

JSE linked an interesting Raspberry Pi case and display here. I can imagine grouping such a display with whatever RAAT zone you wanted it to display. I don’t think the transport style remote would work though, still have to use a Roon control point to control the playback.

1 Like

digging through the youtube video in the post you linking the final product is pretty slick looking and cost seems to be about 25 USD for the case and LED. I guess the question I have is playback control part of Roon Bridge or could it be in not currently? If so i don’t see any reason the remote couldn’t eventually work.

No, Roon Bridge has no Control functions and I don’t think it ever will. It’s Ouput only.

When we build an API, all of this will be possible (DIY or otherwise…no intent to lock this down).

This is a relatively near-term objective for us–it enables tons of good user experience on a wide range of existing hardware, and also allows us to expand in markets that require home automation without necessarily taking personal ownership for integrating with each individual system one by one.

We’re thinking that API consumers will talk to the core via a network protocol. So a display could come up to the server and say “tell me what’s playing on zone X and subscribe me to updates so I can know when that changes”.

Obviously we want to do much more than just now-playing displays. Integrating with external volume controls, source selection, standby controls, and physical buttons in the listening area are important, and we’ll probably do some list-based browsing/searching too.

12 Likes

Excellent news and sounds like the API will eventually provide for some pretty robust things. Look forward to the release and seeing what people do with it.

Great news. Waiting for the API to start exploring what I do with the Rasperry Pi and extending the functionality beyond roonbridge.

First two ideas:

  • cover art and now playing, next up info shown on a hdmi connected TV
  • audio visializer - using Opengles gpu for nice effects

Excellent! As usual, you seem to be approaching things in just the right way. Knowing that this is your stated direction, I’ll do my best not to pester.

Just one nit to pick here (and my apologies for repeating myself so): everybody keeps talking about controlling or displaying info for a zone, and I understand that’s the main model, but for the sort of gizmo I crave to be truly useful it needs to be able to subscribe to updates for a particular physical endpoint, regardless of what zone it’s in. Because I know that in our house, zone memberships are fluid and ever-changing, depending on who’s in what room; but a little display/control box like I envision would be permanent infrastructure to show what was playing on a particular pair of speakers. And a particular pair of speakers is driven by a particular endpoint.

So for that use, the display box would need to be able to subscribe to updates for a particular single endpoint.

(Or it’d need to be able to query the Core and get a handle for the zone its favorite endpoint was in, and also. say, subscribe to updates whenever there was a grouping change for that zone so it could ask again when necessary)

Just hoping this will be in your minds as you flesh out the API.

And also remote controls.

1 Like

We try really hard not to let the word “endpoint” leak into public communication or the application’s UI.

This was a conscious choice–endpoint vs zone is a technical distinction. In very tangible, unsophisticated terms, a user has speakers in their Kitchen, Bedroom, and Office–and that means they have 3 zones. Those zones can be grouped, or not, but it doesn’t change the number of zones that they have. That’s the model.

So, when I said “zone” I was referring to what you are calling an “endpoint”. Because I try really hard never to write down the word “endpoint” in public :). I.e. we are on the same page.

Roon doesn’t have a word that means “N zones grouped together”. That idea is intended to be implicit.

1 Like