In my opinion you are overstating the problem here. The 1st gen streamers were not obsolete after a couple of years, and the current models won’t be either. The original platform ran for well over a decade, and the protocols they use to get music to your system (TCP/IP, UPnP etc.) have hardly changed.
One way or another, all of the new services added to the current platform can be made to work on the old models using simple workarounds, which are pretty cheap in the context of a Naim product, or sometimes free.
But why should people have to use workarounds that apparently compromise sound quality. (qobuz/Hires/chromecast).
I use a Logitech squeezebox touch which is 10 years old. Last week I started streaming Qobus by simply enabling a plug in.
I don’t believe Naim couldn’t very easily enable my Muso Qb Mk1, which is 4 years old, to be able to stream qobuz. After all the SBT qobuz plug in isn’t even provided by Logitech, but a very generous SBT enthusiast.
Well if you have a crystal ball I suppose you can design in support for services that have yet to be developed. In the meantime I’m not aware that anyone has been unable to listen to music on any Naim streamer, it’s just about having the latest must-have feature. Not necessarily in reduced sound quality either. The BubbleUPnP server workaround was widely adopted as an improvement to sound quality as well as making Tidal streams more reliable and adding Qobuz support.
Then enable another plugin and LMS will can send Qobuz and a bunch of other stuff to your Muso over UPnP.
If the hardware power is sufficient, everything else can be done in software. In the first-gen streamers, Naim seemingly made the mistake of underestimating the pure computing power necessary for future advancements and choosing a very poor embedded computing platform. Even though, Tidal could be added, and Qobuz could have been as well, if not for the lack of memory for both.
The new ones seem to have lots of headroom in computing power, a large buffer for online streaming, and a sensible platform that Naim can control (Linux). I was wrong before, but it is difficult to see future advances in audio streaming that can’t be handled by software updates.
My impression is that Naim have always thought long term and have honoured that philosophy through servicing, repair and customer support. There are not many companies who would still be supporting an amplifier manufactured in say 1984…
Granted the “all in one” units must be more difficult to maintain long term, but the philosophy remains, I believe.
It wasn’t that hard, and no different from other complex products, at least there is only standard USB cable required. I have some that are either a custom cable or 9-pin D serial cable connectors.
Firmware updates shouldn’t happening that frequently, for this to be a big problem. If it then the problem is with the software development process, in terms of unit and system testing prior to release.
Well, do you seriously believe Logitech (a computer peripherals manufacturer) was able to produce a streamer (SBT) in 2010 with enough hardware and processing power to stream both Tidal or Qobus. Yet Naim produced a streamer (QbMk1) in 2016 that is unable to stream both Tidal or Qobus.
As I just pointed out in my previous post, Logitech produced a streamer in 2010 that can handle Tidal, Spotify, Qobus and Deezer. I’m sure no crystal ball was involved.
I’ve tried to enable the plug-in that allows the naim QbMk1 to see the Logitech server on the network without any success. I suspect it may be due to the fact I’m using an outdated version of LMS. (Qnap won’t allow the installation of latter versions due to security issues)
With regards to Bubble. I assume you need a Nas or something to run it on. Plus the majority of people won’t have the knowledge to set it up.
You can run Bubble on loads of different devices - Macs, PCs, NAS etc. So almost certainly on something you already own. It took me a few minutes to set it up with no real IT skills, so it’s not hard.
I also got LMS running to play Qobuz, Radio Paradise FLAC and some other stuff on my old NDX. There are also simple ways to get Roon, Chromecast and AirPlay running if you want them, so basically anything that the current gen. streamers can do can be added on.
I think you’re probably under estimating yourself.
My experience is, setting up things on computers don’t usually run smoothly. I quite often end up screwing up, something that was previously working perfectly.
Yes, but that’s still the old platform, no? Like I said, mistakes where made. But once your computing power is above a certain threshold and has some headroom, and if you have full control over the software, it should be quite safe. Data size, for example, has an upper limit. The new platform can do 24bit/384Hz, there will not be more in a long time, probably our lifetime
It seems that the little computer board that handles the streaming on the old platform doesn’t have enough flash or ram memory to handle all the modern streaming services natively.
I believe the problem for the larger data sizes of hi-res is that the buffer in the old platform is too small for reliable online streaming. With local streaming, you have a fast and pretty stable data rate on the network. With online streaming, there can be considerable momentary fluctuations even on fast internet links. It took Naim a while to make Tidal 16/44 work reliably, and I guess 16/44 is the reasonable limit.
Regarding the availability of both Tidal and Qobuz, I believe that the memory that is available to store the firmware is not sufficiently large to contain the code for both. So they choose Tidal over Qobuz, quite sensibly.
For the platform I believe (but may well be wrong) it used Windows Embedded, which was not a good operating system for embedded machines, it was inflexible, I believe quite resource hungry (being Windows), made you dependent on Microsoft (e.g. for bug fixes) as you had no code for it, was consequently barely used in embedded machines, and has duly been abandoned by Microsoft by now.
So all in all, yes, poor design decisions in this platform. But the new platform is looking entirely sane and state of the art regarding what you do when you design an embedded machine. It has a CPU whose power seems appropriate for audio tasks with headroom to spare, it has 50 MB buffer (giving you approx. 2 minutes of fully buffered audio data even with 24/192 flac files), and it uses an operating system (Linux) that is widely used in embedded systems, is highly configurable, and you have control over and the source code for it.
I’m surprised to hear the old green screen units used Windows embedded. Given their very small RAM footprint I’d imagine they’re based on some real-time OS RTOS. Either way the new Linux platform makes a lot of sense and simplifies things like the embedded Upnp server.
But I’m still a bit sceptical. I can believe the earliest Naim streamers may have been lacking in memory, but I don’t believe that could have been the case with later models such as the QbMk1. Is it believable that the memory size in the QbMk1 is the same as that in the earliest Naim streamer.
I think, possibly, you’ve never heard an ND555 of an NDS? You don’t list your gear or location. I assume it’s all Chord stuff?
I don’t mean to be challenging. Just some thoughts.
Cheers.
I may well be wrong on that, I thought I read it somewhere. But whatever it was, some things went wrong with the 1st gen design Some maybe difficult to foresee at design time (when was this, 15 years ago?), others maybe odd - Youtube was founded in 2005 and bought by Google in 2006, internet-streamed content did maybe not come as a complete surprise.
Be this as it may, it seems that Naim have learned the lesson and the old platform becoming so quickly outdated does not mean that this will be the case for every streaming platform necessarily
Some maybe difficult to foresee at design time (when was this, 15 years ago?), others maybe odd - Youtube was founded in 2005 and bought by Google in 2006, internet-streamed content did maybe not come as a complete surprise.