Very technical UPnP question (for Qute)

no one here? or it is not supposed to control this parameters via UPnP and only proprietary?

"...Uh huh. Uh huh. Okay. Um, can you repeat the part of the stuff where you said all about the...things? Uh... the things?"

--Homer Simpson

Hi Okli -

Web control for the Qute via UPnP seems a noble goal. Perhaps Naim technical support could lend a hand? Would seem to be in Naim's interests to help you publish your results...but I could be wrong.

Good luck!

Hook

DLNA compliance for volume and mute commands is not present in the current software, but is intended to be added later, if I recall correctly.

The volume control of the unit is done via a digitally-controlled analog volume IC, rather than within the digital domain, for reasons of sound quality.

This is handled by a different processor than the media player component, such that network control of this requires an additional bit of software to work correctly when using the volume slider in, say, a UPnP AV / DLNA-compliant Control Point app such as PlugPlayer.

David
Thanks for that information. This was being discussed on another thread a week ago, it's slightly disappointing that Naim could not have imparted this information at that time. After all, if it is not possible, it's not possible; sound quality being paramount at all levels.

Regards
Peter

Hi David and thanks a lot for the in-depth explanation.

I thought that the UPnP is just a front-end to the internals of the device and the commands will be converted in the unit accordingly. This explains also why the display will not be updated if the stream is controlled by 3rd party control point applications. I was fooled by the way the nSteam application's interface is designed according to the methods specified in the UPnP specs and thought it is really UPnP conform control point - at least regarding the media player, but as I can understand now it is proprietary, too.
As for the idea with the web interface, I think this is nothing new nowadays and is the most flexible way to add support for all the different platforms available today in a consistent manner. Perhaps someone from Naim could give us some info, what we could expect in this direction in the (hopefully) near future?

Hi Okli,

The Uniti familty has to handle a mix of streaming technologies, for example Apple iPod digital streaming, USB stick, DAB, FM, as well as UPnP.

For the nStream app it actually connects to the device using a container API called netAPI which allows control of all sources in the device, not just the UPnP input. That is one of the key benefits of using nStream over a standard UPnP control point that just does the UPnP source. This API supports volume control for all sources.

We have it scheduled for UPnP control points to be able to change the volume, but we are wrapping it up in some other units of work that will fill in a few other gaps in third party controller support.

Regards

Steve (R&D)

Hi Stevesky

Are you able to say if ...

an ipad version is in the works
and
whether future versions will support cover art more easily.

Tog

quote:

Originally posted by Stevesky:
Hi Okli,

The Uniti familty has to handle a mix of streaming technologies, for example Apple iPod digital streaming, USB stick, DAB, FM, as well as UPnP.

For the nStream app it actually connects to the device using a container API called netAPI which allows control of all sources in the device, not just the UPnP input. That is one of the key benefits of using nStream over a standard UPnP control point that just does the UPnP source. This API supports volume control for all sources.

We have it scheduled for UPnP control points to be able to change the volume, but we are wrapping it up in some other units of work that will fill in a few other gaps in third party controller support.

Regards

Steve (R&D)

Hi Steve,

Thanks for the detailed info.

The magic word is "netAPI", which will remain closed, I suppose? Apart of simple UPnP control it'd be of interest to support disconnected mode b/n control point and renderer because this is another inconvinience currently using 3rd party apps (if you disconnect the contol point the playback discontinues at the end of the track, resp no way to reconnect at a later time - use case is notebook, running the control point app). Unfortunately, the implementation here is not covered by the UPnP spec, so I expect it'll remain "hidden", too. As everything is up to Naim would you share some directions of the further software development - I think there are a lot of users here expecting more info regarding this very hot topic?

Thanks,
Ilko

Hi Ilko,

The NetAPI wrapper API and relevant tools has been currently been released to the first round of integration 3rd parties. As we have limited R&D support and it's quite a complex affair we are throttling the roll-out of it to avoid us getting completely drowned in implementation questions and issues.

In regards to the UPnP side we try to keep it as compliant as possible and we also aim to not to put in custom extensions that inherently mean UPnP is no longer UPnP and force 3rd parties to create custom UPnP control points. We will issue notes of clarification to 3rd parties on areas in the UPnP spec where its open to interpretation and we need to clarify our intepretation of it.


Artwork (question raised elsewhere on the thread) - If the UPnP server supplies an artwork URL in one of the various UPnP container objects we should show it in the nStream app. If there is an issue there then let me know the UPnP server, the file format that the server is hosting (M4A, FLAC etc) and we'll give it a go. We have not done anything unique or custom so it will only work nicely on the Naim UPnP server.

Regards

Steve

quote:

Apart of simple UPnP control it'd be of interest to support disconnected mode b/n control point and renderer because this is another inconvinience currently using 3rd party apps (if you disconnect the contol point the playback discontinues at the end of the track, resp no way to reconnect at a later time - use case is notebook, running the control point app)

Don't understand the rest of what is being discussed here but as far as the above is concerned the way Linn gets round it on their DS range is to automatically load a 'playlist' into the DS when the control point is activated and a CD called for playing. This defaults to the track list of the CD ( or Folder) called for playing, in the absence of a prepared playlist.

Once the 'playlist' is on the DS the control point is not needed and can go to sleep. An interesting side effect of this is you can pause what is playing on the DS, go to bed and start playing where you left off the following morning without having to activate the control point.

regards
Geoff

Hi Folks,

If using the nStream app, it too doesn't have to be active for the Uniti or Qute to stream. Once the Qute is playing the built in UPnP control point that drives the devices front panel feeds the next track to the audio renderer. This allows us to do gapless playback as well.

It also means that the front panel and nStream app are always inherently in sync. Use the IR remote, or nStream (or a mix of the two - eg. want to quickly turn the volume down using IR remote) it doesn't matter.

The Naim solution on how we have resolved the various integration problems has been influenced on that we wanted control for all sources in the box, not just the UPnP. We also wanted to keep front panel always in sync with any wireless GUI running externally. That way if used from front panel using buttons on the unit, IR remote handset or the iPod app the user was always in the same navigation place.


Using the UPnP protocol as spec'd there is no way to do this and the inherent limitations of the UPnP architecture mean that manufacturers have to come up with 'extensions' to fill in the gaps. As soon as this is done then it means that the Control point and/or server (depending on extension) has to appreciate those extensions to use the benefit of them. There is no nice answer to the problem.

Regards

Steve

Steve,

Your explanations are very interesting, as they help to understand the rationale behind the current implementation.
Like you I value consistency.

However there is an area where I do not understand the consistency of Naim's choices.

In another thread, you are clearly stating that Apple is not following UPnP standard but use their proprietary technology (Airport).
This is their usual way (proprietary over open standard)

Now, after choosing UPnP, Naim is choosing Apple technology for the control application.

To summarize, Naim is using non-Apple standard for streaming music, but then is using Apple technology to control it.

As a customer, who knowingly chose Naim and UPnP, I am confused that Naim is pushing me toward Apple.

What does that mean? In the end, does Naim "regret" to have chosen UPnP?

Linn, Logitech and Sonos also use their own proprietary extensions to the UPnP AV spec, so this shouldn't come as a surprise to anyone familiar with the technology.

As for pushing customers toward Apple–the iPod touch is a nice, inexpensive remote control tablet, but it is not required to control the device (the standard IR remote control works just as well). In the same way, Linn, Logitech and Sonos (as well as Meridian Sooloos) also use the iPod touch to accomplish the same end.

Flexibility is important, but I would hardly call development of a control application for the world's most popular mobile OS platform (regardless of manufacturer) inconsistent with a desire to bring the best possible control performance to the product range.

quote:

Apple is not following UPnP standard but use their proprietary technology (Airport).
This is their usual way (proprietary over open standard)

Think your getting Apple mixed up with Microsoft - admittedly Apple's DAAP is proprietary, but it doesn't 'arf work well. OS X is much more open than Windoze, but not as open as Linux.

quote:

Originally posted by David Dever:
Linn, Logitech and Sonos also use their own proprietary extensions to the UPnP AV spec, so this shouldn't come as a surprise to anyone familiar with the technology.

As for pushing customers toward Apple–the iPod touch is a nice, inexpensive remote control tablet, but it is not required to control the device (the standard IR remote control works just as well). In the same way, Linn, Logitech and Sonos (as well as Meridian Sooloos) also use the iPod touch to accomplish the same end.

Flexibility is important, but I would hardly call development of a control application for the world's most popular mobile OS platform (regardless of manufacturer) inconsistent with a desire to bring the best possible control performance to the product range.

David, thanks for clarifying that the choice of platform for the remote application was made for non technical reasons.

Obviously you are right: Naim must offer a solution on the most popular platform. I understand you have no choice in the short term given the market distribution.

The problem is: this platform is controlled by a company who is also offering competing solutions (look how many people in this forum are using Mac Minis, Airport etc.)
Even myself, if I had not purchased a NaimUniti, I would probably use a Mac Mini. And maybe I would be happy with it, who knows?

So my point is: once you manage to "acquire" a customer, why re-open the door to the competitor, by offering features only available on the competitor's technology?

Why offering tablet control ONLY on Apple platform?

I guess what I am trying to say is that it would seem to be in Naim's best interests to offer the remote application on at least 2 plaftorms: maybe Apple because of current market share but also on some other platform independent from competition (browser based UI, Android, etc.).

Thank you very much for accepting such a dialogue.

quote:

As a customer, who knowingly chose Naim and UPnP, I am confused that Naim is pushing me toward Apple.

I would bet that if another company came up with a range of products that define the market segment and offer the implementation of robust third party applications, Naim would jump at it.

The problem is, there are no well defined options/alternatives to the Apple offerings.

This issue REALLY shows the difference (and I couldn't agree more) between Apple products and Macintosh computers.

ps - I am constantly asked why I dont like Macs but LOVE my iPhone. Easy answer.... I like Apple's hardwares and Mobile OS. I dislike their Macintosh OS's immensely. If I could EASILY run EAC, Foobar and Windows ONLY, on a Mac, I would buy a mini tomorrow.

Boot Camp. Painless.

quote:

Originally posted by pcstockton:
ps - I am constantly asked why I dont like Macs but LOVE my iPhone. Easy answer.... I like Apple's hardwares and Mobile OS. I dislike their Macintosh OS's immensely. If I could EASILY run EAC, Foobar and Windows ONLY, on a Mac, I would buy a mini tomorrow.

That's odd because Mac OS X is a much better OS than Windoze in terms of its architecture (no use of shared DLLs), stability (it doesn't crash and every Windoze thing I used is prone to such), openness (Darwin is the core of Mac OS X and you can download the source for free and run it on whatever you like plus 100,000s of free Unix programs will run on OS X) and ease of use (most things are very logical) and software development (you get the dev kit for free when you buy a Mac and XTools is very high quality).

What is it you prefer about Windoze? Only thing I can think of is that you may have a particular application you like that is only written for Windoze, but be interested to hear your reasons.

I've always regarded Apple as just about the best software company around who made some OK hardware, but I'd prefer it if I could run OS X on any computer (without hacking it) rather than be restricted to Apple's hardware. The build of Apple's computer's is not as good as it was since they moved production to China from Taiwan - the superb Titanium PowerBook is a testament to that.

ATB Rotf

Thanks to all for the discussion!

Just to recap my thoughts:

• Flexibility: thus my suggestion to use web UI - we have already web 2.0 and even HTML 5 compliant browsers on all platforms and even if there are inconsistencies between the browsers it won't hurt if, for instance, only Safari and Firefox will be officially supported - these are available for almost all platforms and are free. And you have the server built-in in the unit.
  
  
• UPnP problems: it's not the limitation of the spec - it is its lightweightness, which makes problems. I hope only that this will not end like the other plug'n'p(r)lay concept of one of the UPnP co-founder's company ;-), because at the moment we have 80% extentions and 20% UPnP standard features IMHO...
  
  
• netAPI to integration partners: great news - let see what's comming up for Christmas!
  

...and enjoy the Naim sound!

Regards,
Ilko