BubbleUPnP and playing gapless

I think the Naim app is not different from Mosaic from this point of view: it works with every UPnP server but can only control Naim renderers.

I do not think that one can expect Naim to deliver an app that can control dCS devices and the other way round, of course.

I have a Naim system (nDAC, SN2, Ovator S-400) but no Naim server/streamer and thus no Naim app.

One of the reasons for not using a Naim streamer is that I would not like to have to use the Naim app to control replay.

Yes, I know you haven’t, and I do get your point.

My point though, is simply that any manufacturer who bases control of their system primarily on 3rd party “open” software inevitably lowers performance and quality-of-experience down to the lowest-common-denominator.

I’m sure you recognise thats not what dCS is about :slightly_smiling_face:

1 Like

It doesn’t need to be non-proprietary, it only has to support fairly well standard protocols and open standards.

The BubbleUPnP app is a good example in this respect. It can control devices that implement OpenHome, Chromecast and UPnP/DLNA standards. It is very stable and very well supported.

Other examples of software artifacts that I very much like are MinimServer, MPD and upmpdcli. They work flawlessly and are very well supported.

Examples of software that I very much dislike are the system running on the Naim Core, in particular its UPnP server. Generally speaking, I have found manufacturer-specific software solutions for Hi-Fi devices quite disappointing, in comparison with the products mentioned above. I haven’t tried any dCS software so far.

I do not buy the argument that supporting open standards necessarily implies compromising performance in general. A design can support a standard and still, internally, process data streams in a way that best suits the internal hardware and software architecture. I concede that gapless replay might be a border case, however: I do not know the UPnP and OpenHome protocols in detail.

I don’t think that is the argument. The main argument is that it binds development resources that will not be available to do other things.

That is precisely the problem with this discussion. We are all not experts with these protocols and assume that it would be easy to “simply add gapless” by supporting SetNextAVTransportURI. Unfortunately that is not the case and doing so is likely to open many other cans of worms down the road.