Thanks @Mike_S , 90 miles distant unfortunately.
1 Like
Yes, I understand. I just responded to Guinnless who found the app horrible.
As for installing an app bridge inside the Naim app, I don’t know if it’s feasible.
2 Likes
That can’t be correct @jmtennapel , I don’t have a UPnP server. When using MConnect, it plays Qobuz, the Naim app detects the track as UPnP (source selection icon at the top) and the Muso 1 volume control lights up with UPnP. Unless of course Quboz is acting as the UPnP server?
Yes I understand @frenchrooster.
I think it would be achievable as MConnect achieved it in their app so streaming via UPnP is possible via an app and I think Linn do the same.
Maybe Naim missed an opportunity there…. reference my earlier comment on the collective time we all spend finding workarounds, it must run into man years of effort taking into account all the NDS/272/Muso 1/QB etc. users with Qobuz. If Naim had provided a UPnP upgrade for the app, I’m sure most people would have bought it. Win/win, Naim cost covered and presumably a profit (MConnect is free but a few $ for the full version, they must also make a profit), time saving for us - happy customers 
1 Like
I’m quite sure Naim are aware of MConnect but it may not have given consistent SQ that they were happy with.
As I mentioned previously I’ve not tried MConnect for a while (a few years!) so it may be much better now.
Roon, with SonoreUPnP Bridge into the Naim Network player.
Qobuz - done
Tidal - now with MQA support, to 1st unfold
All other formats (DSD128/256/512, DXD, etc) supported
Better interface & library management
Also it is suggested that handling the processing of the Internet stream on separate hardware to the Network player, as is with Roon Core, gives better SQ, even with the latest models.
1 Like
This isn’t possible: you need a UPnP server to supply content to a UPnP client (in this case your first gen Naim streamers).
This isn’t happening: the Qobuz server is not a UPnP server, or it would “just work” with any old UPnP client.
As has been mentioned a few times, the idea behind the MConnect software is to act as a bridge: it appears as a Qobuz endpoint (client) to the Qobuz server; it simultaneously appears as a UPnP source (server) to the Naim endpoint. To do this bridge function, it indeed has a UPnP server inside. You don’t seem to think of it as being a UPnP server, but it is.
This mode of operation is a whole other software functionality than what Naim have included in their control app. Yes, Naim could license such a solution and embed it in their app: this is technically feasible. No, it is highly unlikely that Naim will go to this great length and expense to support legacy hardware: it doesn’t match their established roadmap and there are already lots of workarounds documented and in use by owners of the older gear.
I think it’s cool that you have this working and are able to enjoy your preferred Qobuz subscription on legacy Naim equipment… it seems like a win to me. Best wishes for good listening.
Well I’m no UPnP expert @alan33 , is everyone being dishonest then when they are clearly stating UPnP is playing?
Beats me how it’s working from MConnect?
Perhaps we are talking at cross purposes, Ross? Nobody is being dishonest, nobody is saying it doesn’t function! I apologize if my post seemed to be accusing you of that! Far from it!! You say it beats you how it’s working; I was attempting to explain that it didn’t work the way you suggested in your previous post.
I was simply trying to say that the software incorporates a UPnP server function of its own, under the covers so to speak … it might appear “hidden” since it doesn’t need to be installed like a UPnP server and running quietly on a NAS or a laptop or whatever. But the app provides these services and that’s the reason it shows up in your beautiful screenshots the way it does.
It’s the purpose of a bridge to translate - in this case to translate and bridge the gap from Qobuz (the source) to Naim UPnP (the destination). These two don’t speak “natively” to each other, hence the need for the MConnect app as the intermediary. The MConnect app is like a simultaneous translator: listening and speaking both languages bdirectionally. It’s an architectural thing, and providing the translation layer is required when two things can’t speak each other’s lingo.
Best wishes. Cool you’re a fan of Ry Cooder, that came out while I was in high school…
1 Like
I don’t understand what you mean by impossible. I have a Melco server and I am streaming with an Nds. I compared both apps for streaming files from the Melco. They don’t sound the same, it’s obvious.
@alan33 , your comments are always positive, sorry if what I sead read differentl. I wasn’t accusing any individual as being dishonest, I wondered if the app, MConnect and the Muso are not really playing UPnP as stated
I can play from MConnect hi-res so I don’t really have an issue, I’m just making the point that I put some time into finding a workaround, others have done the same and many have invested in apps and hardware to make it work, which shouldn’t have been necessary. If they all had Linn streamers, regardless of age, it wouldn’t be necessary. That’s competition and I think when Naim released the Gen 2 streamers they could have done better with the app to keep their very loyal customers on board. Even if the upgrade was chargeable, many would have saved $$$$s on PCs, tablets, NASs, hardware bridges etc. etc. And everything would be available in one app, radio, local storage, streamed content etc.
Anyway, I’ve said enough on this probably, perhaps too much 
so I’ll butt out and carry on being a Naim advocate in all other respects
I saw Ry Cooder live at the NEC many years ago (late 80s?) and have followed all his forays into Mexican, Cuban, African, Indian and other world influences through much of his career. Even his potential inclusion in the Rolling Stones after Brian Jone’s death! That ages me somewhat but since I was very young, music has kept me young in heart and mind
Good to hear Ry has recognition in a younger generation! Enjoy your music, I too would prefer to be listening or at live gigs, as opposed to tinkering or even writing on this forum
2 Likes
I could be wrong but only the Naim App ‘pulls’ the stream and all the others ‘push’ the stream. This may explain the differences.
Running bubblesoft on a NAS is not a significant cost. Esp when you consider the advantages of having a NAS. If you’re buying Naim products this shouldn’t be a problem.
Yes, Nds connected to a switch and Melco to the same switch.
In the three-way controller / server / client model, there will likely be pair-wise connections involving everyone. The audio data will flow from the server to the client (ie from where it lives to where it plays). The controller will help establish the client-to-server connection: it is most likely the controller that scans for servers, gets their coordinates, and supplies them to the target client. Just like the Naim app can scan rooms, and you can select which one to control, it can scan for UPnP servers and establish communication. It can pull down a list of content for browsing, take note of what track you select, and instruct the server to send it to the client. In this sense, the server is “pushing” the musical data to the client (leaving aside all of the bidirectional flow control handling negotiated directly between client and server to manage buffer filling and so on), bypassing the controller completely. If the protocol is for the client to manage the flow, then the sense might better be considered as the client “pulling” the musical data from the server “, again bypassing the controller completely. Either way, server pushing or client pulling, the data doesn’t go through the device running the app… so it isn’t quite right to say that the app “pushes” or “pulls” the musical stream… it just relays user input selections and instructs the client/server pair what to play, when to start, when to pause, when to jump ahead or back, and so on.
It turns out that this three party model is exactly how the “Connect” protocols work: Tidal or Spotify connect, or Chromecast for that matter, use the app to relay user commands to the client/server, but the music stream goes directly from the server to the client. You can stop the app and turn off your iPhone, and all that happens is that you lose your mechanism to change what has been happening… the stream will play until it’s done.
Conceptually, the MConnect plays by two sets of rules simultaneously, I believe… since it’s function is to bridge across two protocols and get the stream to a (final) client that is incompatible with the (original) server. They are probably far more clever than this, but the simplest way to effect such a bridging function is to have the intermediate layer be a client for the upstream server (Qobuz) and be a server for the downstream client (Naim gen 1 player). If done this way, the music data stream does need to go through the device running the app… just like when you use something like Bluetooth or Airplay to stream local content from your phone to your Naim. The difference being that the Qobuz content is only very briefly held locally inside the app: it is just buffering data coming in from the (Qobuz) server and then relaying out to the (UPnP Naim) client. This is also how the Roon bridge software works: an intermediate buffer lives in between the upstream (Roon) server and the downstream (UPnP Naim) client. It’s a middle man, listening to the server then speaking to the client. If it stops running, the connection breaks and the music stops.
I am virtually certain that many clever tricks are employed to make this efficient and robust, but the architectural concepts will be more or less as I’ve said. If it didn’t need to work this way, that would be proof that the client and server could speak the same language (ie use the same protocol)… and you’d have a native endpoint instead of a bridged endpoint.
Ok, flame away…!!!
3 Likes
This is what @Simon-in-Suffolk stated in a previous discussion.
BTW regarding some of your posts above it’s worth noting Naim UPnP renderer in the streamer uses the pull approach… some other control points such as those that control BubbleUPnPServer are server push… which is why there is a difference and why the Naim app won’t work with Bubble… as the Naim app actually communicates with the streamer, for playback functions.
The streamer itself however will accept Naim pull or third party push.
Simon went on to say that he found little difference between the two methods.
1 Like
Nice, thanks @Guinnless
This is actually exactly the same as what I said… the subtle thing to note is where Simon said
The “renderer in the streamer” is the code running in the Naim device, not the controller app running on your phone. We are in complete agreement here.
Also very useful to learn that the Naim renderer can accept server push (how I described the MConnect app doing the translating) as well as initiating client pull. I wasn’t positive if the UPnP protocol allowed both modes, thanks for that clarification.
Good one.
1 Like
How much easier it had been if Naim just pushed the new board into the 272 … or they could just have asked the Sonore guys to make a small enough board to just glue on the inside of the cover.
I know the Naim App has nothing to do with UPnP, I was just using ‘general’ terminology. However in this topic I could see it may have caused confusion. 
2 Likes
You have pushed and pulled, flaced and waved, UPnP severed, NASed and PCed, Spotified, and glued boards.
You have just completed your forth trip around the houses and explored every blind alley on the way.
The OP was a simple question.
I know it is a long time since you were at school.
but 0/10.
Remember to answer the question.
(if you can still remember what it was).
2 Likes