It will! Small App update due this week, and then…
3 Likes
Yeah summer without a year. Let’s see, hope you’re right.
You never know, all this extra testing might be to ensure it works flawlessly on a new streaming capable preamp.
3 Likes
That’s the spirit!
I see what you did there 
🤷
After being a user of Bluesound I can say that they release updates and add features quickly. However they also introduce tons of issues in the process and have just as many updates to fix these. Longer testing periods to iron these would have helped reduce this in the first place rather than rush something buggy to market. All the big boys do this and it’s rubbish.
1 Like
Does this mean we are looking at a firmware update next week then? Or will it be the end of September now…?
I’ve asked for an ETA for both this release and the other updates we’re working on - App updates will come first, then we have various releases for current streaming products, legacy streaming products and Mu-so. Lot of new features and fixes in the pipeline: this isn’t just about TIDAL Connect.
6 Likes
Amazing, thanks for an update.
As an aside, from a development POV, is there a reason Naim choose to bunch all these features & fixes up into one large release biannually, as opposed to releasing fewer fixes but more often? Maybe one for Steve, just seems to be that agile dev is not preferred?
1 Like
Definitely one for Steve not me - but be assured, it’s certainly a hot topic of discussion!
Hi @jstewart01
Do I sense some pitch forks and burning torches near by 
On a serious note, there is no excuse for the delay on Tidal Connect. We had it certified back in November, but a stack up of events have meant that we had to delay the launch multiple times, otherwise we would of ended up introducing quite a few bugs into the Naim streaming eco-system.
Let me explain a bit of how things work internally and why sometimes it can end up with various features all bunched up into one release.
On the core streaming services, Naim use a third party company who develop a stack that has all the stream services in. This is a very fast moving “main line” code base and often large areas of it get recoded so a new feature can work. Typically new security requirements, lower latency, large updates to some core services and so on. Each customer of this third party have code branches and each customer has a dedicated team of engineers who manage the branch + all the customer customisations and product centric bug fixes / integration issues. Naim has about 1600 patches for reference.
To gain any new feature you must take from the “main line” and integrate it back into your branch. This is sometimes easy, other times its a huge unit of work and you can’t just cherry pick one feature - vast chunks must be taken and this often upsets all the patches done in the past + you inherit new bugs from the main-line code as well.
If you’re a tier1 customer (of which we are) then often new features are not debugged by the time we have to merge, so its a battle to get code stability as all the suppliers debug and often do radical last minute changes to their code.
In parallel we have:
- Streaming services like Google, Apple, Tidal, Spotify all wanting library updates pushed out into new releases. Some we are under contractual obligation to release.
- End of life hardware components. For example, front displays which can introduce a huge amount of software work and also block production if we don’t do it in time.
- New product development - all those lovely new products don’t make themselves
- General bug fixes to keep the peace with other apps that have changed how they work. Quite often these fixes are quite niche, but rather critical to a customer if they have that stack up of requirements to trigger the bug.
- Recertification of code - unlike opensource code, we have to go through official cert labs and this can take months.
- Sound sign off to get everything electrically all balanced so it really sings.
- All the code stacks & apps that we do inhouse that fit on top of the streaming stack and the n’th other dedicated processors in the devices. This is not just a third party exercise as a huge amount of code is developed at Naim as well.
So inhouse we use pretty modern development techniques (Agile, all tracked in Jira, daily standups, MoSCoW priortisation etc etc), but the reality is that nothing will pause if something delays a unit of work. The new libraries updates keep on stacking up, the new “must have” features keep on arriving, etc etc. so if we focus just on getting one feature out, all the rest then build up and we have big problems 6 months later.
Overall though, the v3.7 release is very close now and it carries a lot of good stuff (some hidden…). We’ve had it in public beta for quite a long time, but we want it right, and not be going from one collection of bugs to a new collection of bugs. The current production v3.6 release represented a lot of work to get a stable codebase and as you can tell from the forum, the amount of quirky issues being reported have dropped off massively.
I hope that clarifies a few things and gives a bit of insight of what goes on in the world of R&D.
Best wishes
Steve Harris
Software Director
Naim Audio Ltd.
25 Likes
Thanks for the update, though my eyes glazed over I’m afraid…. that was all a bit over my head…
I think that’s the very point: it’s far from as simple as many people imagine!
3 Likes
Couldn’t have asked for a better response, really. It sounds like the major changes / feature additions then come from this third party source, then there are a couple of rounds of bug fixing/branch integration/other patching that are done both on the 3rd party-but-specifically-for-Naim side as well as internally within Naim (and I guess on “your branch” from the third party).
I’m intrigued as to what the 1600 patches for Naim specifically are and why they don’t end up back in the master branch of the 3rd party - I guess this would encompass things specific to Naim and IP issues…?
I’m sure you (and others) can now appreciate the frustration we share with the time delay of TC - it is of course tough when not everything is controlled in-house, and I certainly do hope that we don’t get a slew of new bugs!
Thanks for taking the time to respond.
Plus 1
1 Like
Hi @jstewart01
re: patches
There are two ways to make a streamer:
-
The quick way - take a reference design using latest tech, grab the “main line” code, customise it a bit, pop it in a box, certify it then sell it. Do very few software updates to it then 2 years later discontinue it and repeat around the same process. Expect all customers of old product to sell it and buy a new one.
-
The Naim way - we support long term platforms that last for well beyond the normal life of tech consumer electronics. On the software side we have to ensure that the code base has backwards compatibility, support older CPU’s (this can be tough), plus in a fast moving business often the mainline code is more about quantity, rather than quality. We have tons of bug fixes that other manufacturers don’t have, as we want the platform to be right, not just be a race to bash out the next wizz-bang tech product. We also have quite a bit of “magic sauce” as well that makes our solution far superior to the reference platform, from better audio clocking, audio buffering, different protocols to interface to the DSP etc.
Overall, Naim are in the Streaming game for the long-term, and hence we have to avoid cutting corners and doing throw away tech that gets you quick to market, but makes the customer suffer buying into a dead-end solution.
Best
Steve
19 Likes
This is the most reassuring thing to me. Too many play this game especially in the lower price brackets. I feel I will be able to use my Atom for many years to come.
2 Likes
With digital becoming such an important part of Naim. Wouldn’t it be time to move sourcing and rely on 3rd part partnerships and take more control? I assume this will continue to be an issue if nothing is changed. Obviously others do it “better”. Outsourcing is often a fast short term solution IMO and the more you get in-house the more control of it all.
Looks like they already have some degree of control, based on the number of Naim-specific “patches” in the software. Outsourcing is often times a balance, between what you get (more control, etc) and what you lose (additional investment, more people, management time and attention, need to attract talent, etc).
If control is critical to the health of the Naim platform, they should evaluate whether they have the talent to (transition/acquire/build from grounds up) and run all the bits in-house. Doing this will take effort and investment, will likely take a year or more, during which other development, features, etc will be affected.
1 Like