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
Hi @Blackbird
In an ideal world it would be nice. But in practice often you end up reinventing the wheel + the large tech companies like Google, Apple, Amazon, Spotify etc. donāt want to be supporting and certifying lots of different platforms nowadays. Theyāre all focusing of that a few system integrator (SIās) do the work and then lots of big manufacturers all benefit from a known code base. The art is to work with that SI and create something special and bring something to the relationship. In Naimās case weāre a pretty strong software house and a lot of key features run on the Naim platform before others get it as we have the skill to debug things when the going gets tough. Many others are driven by project managers who tick a box of a wanted feature and expect it delivered, with no idea on how it works.
Best wishes
Steve
9 Likes
Thanks Steve - makes all sense and is the absolute right long-term strategy imho (coming from SW industry myself). But also please do not forget and put last your customersā requirements and desires for state-of-the-art and leading UX, useability, āse.yā F&Fs, plugnplay and compatibility! Naim still lacks respective quality in their SW - and in HW more and more as well, unfortunately. Compete with the best in these fields (such as apple) but not with 3rd party suppliers constraints! Naim customers are willing to pay premium prices for best in class performance - but not for regular crashes and bugs of their 555ā¦.
Hey Clare - did you get an ETA wrt this?
App updates are with Apple/Google for review; TIDAL Connect firmware update is in listening phase - thatās final phase before releaseā¦
4 Likes
If it pass that phase yes 
It stays in the listening phase until itās ready for release. Only when sound quality is signed off does it leave the buildingā¦
4 Likes