Why Naim's failure to update firmware actually does matter....

Jan-Erik Nordoen posted:

Flummoxed posted:

Is there any word on ROON being included in any forthcoming firmware upgrades?

I currently use it in my office on a Mac via KEF Egg speakers and love it.

The software functionality and information it provides creates a totally new listening experience which would be wonderful on naim streamers.

Not quite. It provides a very rich metadata experience but does not improve the listening. I trialled it, then again with MQPlayer but found neither as musically interesting as Audirvana +, which is close but still not as good as the listening experience I get from the UnitiServe. Naim has always been about engagement with the music. Why compromise that just to add new features ?

Thanks for the response Jan,

Apologies, perhaps I wasn't that clear in my post.

My phrase "totally new listening experience" was not intended as any opinion re sound quality from Roon, but the way in which the Roon content and interface enriches the experience of listening to music. 

Whilst I thoroughly enjoy the Naim app when using my 272, Roon I feel would very much enhance my enjoyment and engagement with the music.

What prompted my initial post was the fact that i'm looking at how can I connect the Roon Core that sits on my Mac, into the 272. I've looked at the new SONORE microRendu which would then require a USB DAC, but it ends up getting costly especially if Naim have plans to integrate into their streamers.

I hope that makes sense?

Hi there Guys,

thanks for all the comments on this and please be assured that Naim will only release software that meets our exacting standards about Software Quality Control together with providing the best possible user experience. Only when we are happy that these factors have been fully addressed will we push out for Public consumption.

Thanks

Mark

Thanks, Mark - it really is appreciated that we've finally got something from Naim. But frankly your comments could have been written by a PR agency, and don't really move us further forward. Some acknowledgement that this was expected before Christmas, and that's it's now a very sunny May Day would be appreciated. No one wants you to rush these things, but...

And as a software tester for a major (i.e., Fortune 11) health care company, I can vouch for the need to emphasize quality over "getting it out the door."  We have focused exclusively on the latter over the past 2+ years and it has resulted in us having a truly s**t product, to the point that when my father went to the hospital about a year and a half ago and was in one of our customer facilities, it gave me pause to worry.  Not a good thing.

We tell them it is not ready, but the top execs (and their corporate Kool-Aid drinking sycophants) are, well, idiots, to put it bluntly, (albeit 7 figure idiots for the top dogs) and out it goes - with the subsequent result of many service orders from our customer base, lost business, tarnished reputation, hot fixes flying all over such that NOBODY is running the same software, and loss of faith in the product from the very qualified work force we have...employee morale is in the toilet.

I have always maintained that our customers might be irritated if we miss a release date, but that will be minor (and pretty quickly forgotten) if the software works great when they get it.  Instead, they get crap...but they get it on time.  (The rumor is the top exec in our division get bonuses based on meeting the dates - I don't know if that's really the case, but it would go a long way towards explaining why things are the way they are at our division.)

So Naim is doing the right thing in adhering to the highest level of tolerance on software quality..perhaps their only fault was not communicating to the customer base about what was happening and at least letting them know it hadn't fallen off the radar screen.

Whatever you do Naim, don't do what my employer does.  Ever.

The question I used to ask my customers when I was in the software delivery business was:

"Do you want it right, or do you want it right now?"

But I must admit I viewed it as a failure if we got to this level of "discussion" .. regular, honest progress updates alleviate a lot of the acrimony and frustration (as GOON525 points out ..)

It isn't easy but it isn't rocket science.

I don't remember anyone on here asking for the FW update to be rushed out the door before it is ready. That would be stupid and we are all agreed on that. All we are asking for (if I may speak for others) is some update 4 months after we were told it would be released. That's all. Not unreasonable I would have thought.

Thank you Nigel .. you made my point perfectly.

I don't think anyone has suggested rushing out software that isn't ready, just asked for better communication.

Imagine you are standing on a train platform waiting for your 7am morning train to work. Now the train develops an important safety failure and it won't be fixed and ready to transport you until 10am (estimate).  Would you like to know what is going on and be kept updated, or be told nothing?

DavidDever posted:

rjstaines posted:

...There is one lesson to be learned that not all users of technology grasp, however, and that is that once your organisation has dipped its toe into the computing technology pond, it becomes essential that you henceforth regard that discipline as an equally important partner to your original core business.  So, for example, a retailer who adopts computer automation needs to start to regard himself as both a retailer and a technology business and make appropriate investment in both aspects.  'Appropriate investment' means not only hardware but also people... software experts in fact, designers, coders & testers.   I faced many struggles to get this message across...  

Amen to that. Same applies to distribution partners, as well - there are no shortcuts. Get out of the business if you're scared of change.

Indeed - but this is more than programming - or using the bizarre vernacular of 'coding', being a computer engineer - instruction set programming coupled with the interaction of hardware is fascinating engineering - as controlling state machine hardware by specific instructions has specific effects and cross talk effects within  systems..ie affects SQ in this area.  I used to love this part of the computer engineering and small system development and got tripped up by it many times - my career has moved away from this now - but I suspect this is a key  area that Naim are managing, grappling and mastering and IMO its light years away from the majority of contemporary app 'coders' and 'hackers'  where such interactions are largely irrelevant and I suspect quite alien...

Simon-in-Suffolk posted:

DavidDever posted:

rjstaines posted:

...There is one lesson to be learned that not all users of technology grasp, however, and that is that once your organisation has dipped its toe into the computing technology pond, it becomes essential that you henceforth regard that discipline as an equally important partner to your original core business.  So, for example, a retailer who adopts computer automation needs to start to regard himself as both a retailer and a technology business and make appropriate investment in both aspects.  'Appropriate investment' means not only hardware but also people... software experts in fact, designers, coders & testers.   I faced many struggles to get this message across...  

Amen to that. Same applies to distribution partners, as well - there are no shortcuts. Get out of the business if you're scared of change.

Indeed - but this is more than programming - or using the bizarre vernacular of 'coding', being a computer engineer - instruction set programming coupled with the interaction of hardware is fascinating engineering - as controlling state machine hardware by specific instructions has specific effects and cross talk effects within  systems..ie affects SQ in this area.  I used to love this part of the computer engineering and small system development and got tripped up by it many times - my career has moved away from this now - but I suspect this is a key  area that Naim are managing, grappling and mastering and IMO its light years away from the majority of contemporary app 'coders' and 'hackers'  where such interactions are largely irrelevant and I suspect quite alien...

Umm....I'm getting a little confused by this line or argument. I totally accept that Naim have been dragged (possibly kicking and screaming) into the digital arena and now have to develop the managerial and technical capabilities to develop software and indeed digital hardware. That takes time as it is actually a change in direction from their core competencies of designing, developing, manufacturing and marketing analog hardware with the addition of some limited competencies in the digital realm (I am referring to CD). But streaming is a whole new ball game and it will take time, investment and a whole new band of skilled (digital) technicians and designers to, first catch up, and then to lead in this relatively new field of streaming audio.

But retailers don't necessarily need to evolve to such a degree. I do accept that retailers do need a whole new skill set to be able to sell, install and advise on all things digital (I'm specifically referring streaming technology here). And this is not helped by the fact that we are ALL still learning about the finer details of tuning and getting the best out of the front end of a streaming system. By this I mean the supposedly simple domestic Local Area Network. Here retailers do need to up their game in my view. There are too many uninitiated retailers out there giving ill-informed (or no) advice on how to put together, optimise and operate a good streaming system fronted by a capable and optimal domestic LAN.

So lots to do, much to learn and many lessons to be understood by both manufacturers and retailers in this brave new world of audio streaming. Most importantly however all this new learning has to be passed on to us poor old consumers, many of whom are from a non-technical background in order to fit that final, but most important, piece of the puzzle. If we don't get it or are frightened off by it, then it is all a rather expensive waste of time and money.

Is it worth the investment, effort and risk in developing the technology and recruiting the people at both manufacturer and retailer level? Damn right it is. I am absolutely gobsmacked by what I hear from my streaming system. The fact that I can be so moved by some music I have heard before, that has never moved me before makes this whole new world worth it. Well to me anyway.

I understand that what you are waiting for is a fix. So the first time was right now and not right.

Then the "best possible user expirience" was poor and many months are needed for a second try.

Am I lost?

Regards.  Erich

Erich posted:

I understand that what you are waiting for is a fix. So the first time was right now and not right.

Then the "best possible user expirience" was poor and many months are needed for a second try.

Am I lost?

Regards.  Erich

 

Don't know if you are lost, but I am sure I am!

MarkR posted:

Hi there Guys,

thanks for all the comments on this and please be assured that Naim will only release software that meets our exacting standards about Software Quality Control together with providing the best possible user experience. Only when we are happy that these factors have been fully addressed will we push out for Public consumption.

Thanks

Mark

nigelb posted:

Erich posted:

I understand that what you are waiting for is a fix. So the first time was right now and not right.

Then the "best possible user expirience" was poor and many months are needed for a second try.

Am I lost?

Regards.  Erich

 

Don't know if you are lost, but I am sure I am!

I'm presume Erich means that if Naim only release software that meets their exacting standards, then why are we waiting for an upgrade to correct things from the last release that met these exacting standards. 

( now I know why, so don't flame me, but I feel Erich has rightly noted some chutzpah- if that's the correct word- in Mark's explanation for the delay)

SJB

Reburner posted:

I don't think anyone has suggested rushing out software that isn't ready, just asked for better communication.

Imagine you are standing on a train platform waiting for your 7am morning train to work. Now the train develops an important safety failure and it won't be fixed and ready to transport you until 10am (estimate).  Would you like to know what is going on and be kept updated, or be told nothing?

And I wasn't saying anyone was - I was lauding Naim for doing it correctly, and pointing out that I have first hand knowledge of companies that don't. And as you correctly indicated, a little communication will go a long way.

Over my desk is a sign: "Why is there never time to do it right, but always time to do it over?" Apparently this type of thinking keeps me on the bottom rung of the corporate ladder, while the 7 figure boys think otherwise. Maybe I should change my way of thinking...

Sloop John B posted:

MarkR posted:

Hi there Guys,

thanks for all the comments on this and please be assured that Naim will only release software that meets our exacting standards about Software Quality Control together with providing the best possible user experience. Only when we are happy that these factors have been fully addressed will we push out for Public consumption.

Thanks

Mark

nigelb posted:

Erich posted:

I understand that what you are waiting for is a fix. So the first time was right now and not right.

Then the "best possible user expirience" was poor and many months are needed for a second try.

Am I lost?

Regards.  Erich

 

Don't know if you are lost, but I am sure I am!

I'm presume Erich means that if Naim only release software that meets their exacting standards, then why are we waiting for an upgrade to correct things from the last release that met these exacting standards. 

( now I know why, so don't flame me, but I feel Erich has rightly noted some chutzpah- if that's the correct word- in Mark's explanation for the delay)

 

SJB

OK, I see that Naim could be accused of releasing the current FW before it was fit for us consumers. But I don't believe Naim would have released it in the knowledge that it would not provide 'the best user experience' at the time - call me naive. As I mentioned in my previous post, we are all learning, none less than Naim themselves. Audio streaming technology is relatively new and is still developing fast.

I am sure Naim do not want to make the same mistake (if it was a mistake) twice, hence the delay. My only gripe is that we have not been kept informed which has served to tarnish Naim's impeccable reputation IMHO. I would like to think we are all (well most of us) realists on here and would have completely understood if unexpected technical issues were to blame for the delay. The mistake was to start to update us and then deafen us all with silence for 4 months.

Right I am now starting to repeat myself so I am out of here!

..."under-specced systems lead to bad user experiences; hardware is cheaper than ever and getting cheaper all the time; don't over-economize if you want the best result."

Personally, I find the crippled-in-favor-of-sound-quality arguments tiresome; any engineering challenge can be resolved when the efforts of the best and brightest are brought to bear upon it. That said–in a niche industry such as specialty audio, there is little economic incentive, unfortunately, for maintaining total control over the design of embedded hardware as well as all phases of software development / integration / deployment.

Those that do control the top-to-bottom software and hardware platforms accelerate products to market faster, as they're not tripping over someone else's dependencies, and likely unbound from others' ill-considered resource constraints. Of course, some manufacturers and consultants benefit additionally from work-for-hire outside the residential consumer electronics market space, which provides them with valuable experience and perspective, and, in some cases, skill and expertise that could never be paid for with the profits from sales of audio products alone.

In the case of retailers / distributors, though, technical agility pays off rather quickly - products can be vetted for automation and deployment (or pre-rejected in the interest of saving many hours of exasperation) prior to demonstration and/or sale, while maintaining a maximal standard for user experience that one's customers expect. There's no excuse for supplying technologically-stillborn products into the market, nor for artificially propping up manufacturers that do.

Reward the manufacturers that look out for your long-term interests with your purchases, but do be sure that they're looking out for the long haul as well, and not simply (if not cynically) re-badging someone else's solution to maximize profits in the short term.

Nigelb, not sure I followed your argument with respect to my observation. My point is that with our Naim components SQ is key. SQ is affected as we know by noise and cross talk. In the would of digital audio there are many variables in terms of transmission and codecs.. the processing of this within a systems causes interactions or perturbations with other sensitive audio related functions like digital clocks and analogue stages.. Therefore the software engineering skills required to develop the instruction sets that produce the operational function but in a way with as benign as possible impact on interference is a key and to my point arguably a relatively rare skill in these days of mass software programming and development. It is these skills that I believe Naim are mastering.

Streaming itself has been around for a relatively long time now .. For me it all started in the late 90s, just ten years after I started with CD, but codecs and transmission, as well DAC technology back then meant streaming rarely if ever competed with CD or vinyl and so was used more by the technologists back then rather than the 'audiophile' or even mainstream. Things are different now.. and so impacts on SQ on higher quality audio equipment are more noticeable within combined systems. After all the lossless FLAC vs PCM WAV preference is a classic example of this.

I believe the future of high quality digital audio will incorporate optimised code and very low power FPGAs where the perturbations can be kept to a minimum more easily... That is the future will continue to be the development of the close relationship between software and digital hardware. Thinking its software only in my opinion is as misguided as thinking bits are bits. I am confident combined hardware/software skills being developed by Naim now will be carried forward with more effect in future digital audio product development.

Simon

Thanks Simon,

So are you on the beta or production firmware during the extended period of not testing?

Keith

We are all running the beta firmware and beta apps. 

Keith, as part of the beta team I am evaluating pre production firmware and software during this period of testing for Naim

S

Delicate issue raised by Keith - in that the argument for waiting on code improvements for production is being made by folk who currently benefit from improved but still beta (non-public)  firmware...ie by folk not waiting.

Classic dilemma for developers, to offer or deny a public beta. The pros (access to not-ready-for-prime-time features and fixes, a voice in the development sphere, a glimpse of how the company is deploying resources to address improvements...) and cons (no guarantee of support to testers, larger numbers of people suffering from pre-production bugs and issues, mistaken belief among customers / testers that there is no risk from running a beta because it's just software and what could go wrong...) are diverse and complex. 

This topic is age old and Naim have a clear policy of controlling information until release. Those suffering from the Tidal drop out problem to the extent that they are frustrated and considering other hardware might do well (or at least better than they are in this forum) to speak to Naim in a private email to support. I think the message delivered here that announcing a fix by Xmas and failing to release by May Day has been heard - but it's not obvious that this is heard uniquely as a call to speed up a process that is taking a long time or as a reminder to avoid any future announcements until release day. Irony everywhere hereI

I don't have the answer. My own experiences with an early Qute suffering from bad connectivity and strange error conditions that affected both network and ir remote functionality  were the reasons I joined the beta program in the first place. It was an unusual error use case and provided a good test point for the development team.  I continue to participate even though I have not suffered from most of the issues being addressed and, as with the new BBC radio formats available only to UK residents, I don't even have access to some of the services being introduced. It's a way to contribute as well as a way to see what's coming next. But it is definitely not for everyone, and heart-stopping moments when things go sideways during testing are real and not something every customer (including those with network, hardware, or general technical backgrounds) should or would want to participate in. Nor can Naim manage an infinite pool of testers, of course. 

Rambling finished, thanks if you read this far. 

Regards alan

alan33 posted:

..............  the argument for waiting on code improvements for production is being made by folk who currently benefit from improved but still beta (non-public)  firmware...ie by folk not waiting.

Not so ..........  beta testers are also waiting ...........  with nothing to do. 

Mike-B -

i don't want to discuss the beta program here, but others have already indicated that the current beta includes better Tidal service than many on the production code experience. I simply meant to acknowledge that Keith's point about advocating waiting for perfrct code is a little suspect when it comes from people who have taken the risk of joining the beta program rather than choosing (being constrained) to wait. I wanted to address the sting from both sides and now recognize that I likely failed if you chose to read my post and disagree with a point I wasn't making - my apologies.  

Regards alan

alan33 posted:

Mike-B -

i don't want to discuss the beta program here, but others have already indicated that the current beta includes better Tidal service than many on the production code experience. I simply meant to acknowledge that Keith's point about advocating waiting for perfrct code is a little suspect when it comes from people who have taken the risk of joining the beta program rather than choosing (being constrained) to wait. I wanted to address the sting from both sides and now recognize that I likely failed if you chose to read my post and disagree with a point I wasn't making - my apologies.  

Regards alan

Suspect . . . as in you think they are being disingenuous?  I don't think you mean to besmirch.  

But I get your point; there is a certain sting to it, I understand.  But it, I am quite certain, does not emanate from a bad place on the part of the beta testers.

.......   oophs sorry Alan, nothing so serious in my intent,   I was just making a light hearted jest about how it is for beta testers at the moment.