BubbleUPnP and playing gapless

[nbpf]

@solwisesteve

Well I’m 99% sure the NAIM products do. Okay you can’t adjust Phase Inversion or balance but, honestly, how often do you want to do these functions anyway? However the NAIM app has better gui and operation and works correctly with just about any upnp server.

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.

[nbpf]

@Anupc

Right, got what you mean! . Are there any Naim users who don’t use the Naim App? Presumably they’ll need to juggle multiple apps just control playback then.

By the way, I did a quick google search, looks like Naim also contracts StreamUnlimited for their NP800 board. So, it’s really all just down to the UPnP stack on the streaming board then .

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.

[Anupc (Anup)]

@nbpf

I haven’t written about volume control, filter selection, balance control, phase inversion, etc.

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

[nbpf]

@Anupc

@solwisesteve

Well I’m 99% sure the NAIM products do.

…
@nbpf is arguing for a non-proprietary (“open”) UPnP Control-point to work with dCS for gapless, and presumably control all the other often used dCS features as well.
…

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.

[nbpf]

@Anupc

@nbpf

I haven’t written about volume control, filter selection, balance control, phase inversion, etc.

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

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.

[jacobacci (Rudi)]

@nbpf

I do not buy the argument that supporting open standards necessarily implies compromising performance in general.

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.

@nbpf

I do not know the UPnP and OpenHome protocols in detail.

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.