Hi everyone!
I am returning to this topic of SenseUPnP as we have some more changes planned for this feature in forthcoming software updates, of which I will provide some new details and will again involve some feedback from the Community Forum.
Before that, however, some broader context and clarification should be given to SenseUPnP as a whole, as it is something that I feel could benefit from some wider explanation of its origin, purpose, benefits, and limitations.
So, let's start with the basics!
What is SenseUPnP?
SenseUPnP is a feature whereby the Innuos system could send its audio across the network to a selected external UPnP streamer/player. It was first introduced in update 2.1.0, roughly 1 year after Sense app and 'innuOS 2.0' was first released.
Why was it introduced?
The improvement in the quality and UI that came with Sense and its continued evolution saw a growing transfer of interest from users wishing to use Sense to navigate the library and control playback, instead of using the native app that came with their third-party streamer(s). We therefore felt a growing obligation to work on such a feature, which would add quite a unique functionality to the product and add value to it.
Sounds simple enough?!
Not quite! This is a reversal of how UPnP normally works. It is the job of the UPnP streamer to pull files from a UPnP server, but SenseUPnP offered the reversal of this whereby the UPnP server (Innuos) was pushing audio to the UPnP streamer, as it were.
Why is that a problem?
Because UPnP has a great number of variations, and has been implemented in countless different ways across streamers meaning that the overall results were quite mixed and inconsistent across different products. These limitations are inherent, so was a very 'your mileage may vary' feature. There is no easy 'one size fits all' for UPnP, otherwise this type of feature would already be very widely available from many other app developers. (This is also why we see alternative ecosystems such as Roon and Squeeze that bypass the limits of UPnP altogether).
Our approach was to use 'profiles', creating a set of pre-configurations that seemed to reliably work with specific streamers. We also had a 'Default' one that was designed to work with the widest number of common UPnP devices as possible.
Sounds good, problem solved then?
Not quite. The range of profiles needed to cover all streamers on the market is virtually limitless, and not to mention constantly evolving since some of these product platform will be altered by software updates (meaning a new re-configuration and re-testing of SenseUPnP Profile). It is a huge ongoing task, and diverting resources to this comes at the expense of developing other features.
So it wasn't very feasible?
No. What was more feasible instead was a new UI implemented in 3.2.0, allowing a small set of customisable options to be adjusted by the user to account for different streamers, and see what worked best on a system-by-system basis. It also included some new adjustments to make 'Compatibility Mode' work with as many more devices as possible. The idea being that even if Compatibility Mode did not work, then there would be something very technical/particular/complex about your streamer.
And what if Compatibility Mode was still not stable for me?
This brings us to the very basis of SenseUPnP; it is provided as-is and is a feature of convenience, not outright performance. Our focus is producing streamers that makes your main HiFi sound as good as possible, and Sense is primarily tailored to this.
It is not designed to be a universal remote ecosystem to take over from the applications of other streamers, phones, laptops etc. If the native software for your streamer is insufficient for you then SenseUPnP might be a potential alternative but it is not guaranteed. In essence, it is using a streamer to stream to another streamer. SenseUPnP is a bridging feature.
It would be like being sat in the back of a taxi driving you home and having to shout directions at the driver, who may or may not have any clue what you are saying or where you are. Wouldn't it just be easier if you were the one driving? The point here is that in many cases, it is much better to have the Innuos being the actual streamer.
But Ethernet is just a normal audio output to a DAC?
I cannot emphasise this enough - no it isn't. If your DAC has an Ethernet input, then the chances are this means it is also has streaming abilities, and it is in fact that streamer that is the master player in charge (which is a very big determining factor in sound quality) even if using SenseUPnP to control the music library. Along with using the 'Streamer' port, it can certainly give the illusion that Ethernet is a direct audio connection, but it is not an audio output in the same way USB or SPDIF delivers an audio signal.
Point and case, does your UPnP streamer have WiFi? If so, remove the Ethernet cable between it and the Innuos and enable the WiFi on your streamer. Notice that SenseUPnP still plays to it? In other words, using the Streamer port is not just a case of changing from another cable like USB.
So what is the second 'Streamer' port for then?!
The Streamer port is there to provide a dedicated low-noise network connection for your external streamer on the assumption that your Innuos is functioning as a music server only. This removes the need to add a network switch which can often introduce a lot of noise if using a basic IT one (although a decently-designed switch for audio would actually bring an improvement as evident by PhoenixNET).
The hardware and design of your Innuos is leveraged more when it is the one actually producing the audio signal via its direct audio output, be it USB, SPDIF, Analogue and so on. This is why the 'USB vs Ethernet' debate does not make sense, and what is actually being asked is whether an external streamer might sound better than the streamer inside my DAC/pre/amp. It is not a question of cable or connection type, but who is doing the streaming. Keep this in mind when assuming your DAC reportedly has a 'better optimised Ethernet input', because what this actually means is they suggest using their own on-board streamer, and not an external one. This does rather depend on what external streamer is actually being used/tested...
I understand that, but I am actually trying to use SenseUPnP to a wireless speaker or active system...
That's fair enough - SenseUPnP might be the only way combine Sense app with that speaker/system because it has no conventional audio inputs. Some Sonos speakers are an example of this.
So despite all this mentioned above, SenseUPnP is carrying on?
That brings us to the next steps - yes! Our plan is to carry on with it's existing design, but over time we will begin to add 'certified devices' that we have had sufficient testing on, a lot of which will be from willing beta participants. When a tested UPnP device is detected by your Innuos system it is automatically identified and pre-configured. As per the Sense 3.4 beta that I recently posted on, we have added a couple of Naim systems.
Is this a return of the profiles system from before?
In a way, yes, but much more neatly integrated and more automatic from a user perspective.
Hang on, I thought adding profiles was a "huge ongoing task"?
Right - so we need to be realistic about the scope of this, and have a different set of parameters.
- This will be an ongoing process, and new certified devices will only appear gradually over time.
- We must be selective about what devices to test and add. As mentioned above, active and wireless systems do make sense because sometimes they cannot easily connect to the Innuos another way. Examples of this might include Sonos, Devialet Phantoms, Naim MuSo, KEF LS50W etc.
- Streamers that we see used by a lot of our customers will be prioritised - Naim and Linn being the two biggest examples by far (though i do still maintain my earlier point of having the Innuos take over as the streamer if you wish to use Sense app to its full potential!).
- Streamers that are discontinued, end of life, and no longer supported are dramatically less likely to considered. We have to be pragmatic and utilitarian about this and consider products with longevity. Certifying streamers that are 10+ years old or more is not very efficient, when really some consideration should be given to just replacing the streamer itself.
With this in mind, we are open to suggestions of devices we should prioritise but do please remember the points above; there needs to be a strong argument for a device to benefit a lot of users, so we cannot take requests to support an AV receiver build 15 years ago.
Furthermore, we would likely need you to become a willing beta candidate to test a custom profile before we include it in a full release. It is not easy for us to acquire all these products and run them at our HQ, so this is very much where you come in!