Firmware updates and sound quality

[Simon-in-Suffolk]

I don’t disagree, what with room colourations such things can be really useful.

[adeypoos]

Thanks for the replies fellas. Interesting stuff and above my head. The tone control option on the app is a great idea and one I have mentioned, amongst others, on the forum before. That one can have user control on tone and frequency response on sound rather than the somewhat “random” effect of a firmware update would be a bonus and a marketable asset for Naim when selling their products in my view. I have considered Roon as a possibility just because of this and even though I have resisted so far it would be nice to have it “in house” so to speak.

[adeypoos]

Where would this have the most impact? Usb inputs or on streamed services like Qobuz?

[Simon-in-Suffolk]

It’s common to all inputs… It happens on the digital/DSP/clock circuitry rather than the streaming circuitry.

[jsaudio]

I’m not great at describing subtleties in SQ but it seems that I have to increase the volume relative to prior to get the same “involvement “ and detail but then sound becomes somewhat harsh. Low volume quality has suffered.
Thanks for asking @Thomas

[davidng]

@Simon-in-Suffolk

firmware changes can change the code execution timing which in turn controls the timing of digital currents read and writing to memory or CPU execution… this in turn changes or ‘shapes’ the conducted noise in ground planes, electro magnetic coupling and internal powerlines.
This reshaped noise can interact with digital clocks and analogue circuitry to produce an audible affect.

@Gazza

it is subtle changes to the electrical floor noise in the Core processor…after a firmware is fixed for release the sound team tweak the noise floor to ensure it is the same or better.

There is a considerable number of posts about SQ change resulting from firmware updates. Whilst I think I did hear some subtle differences, my mind tells me it may be temperature or even humidity that may contribute to the difference. I am sure firmware development team is not doing anything intentional with regard to SQ but merely addressing reported issues and adding features as they are ready. I don’t believe there is built-in machine learning that gets flushed by firmware update. Please tell me if I am wrong.

Really appreciate these two comments from @Simon-in-Suffolk and @Gazza. I don’t really understand processor electrical noise floor but timing seems completely plausible. Perhaps someone from Naim can provide some insights, please. Thank you.

[Simon-in-Suffolk]

@davidng

There is a considerable number of posts about SQ change resulting from firmware updates. Whilst I think I did hear some subtle differences, my mind tells me it may be temperate of even humidity that may contribute to the difference. I am sure firmware development team is not doing anything intentional with regard to SQ but merely addressing reported issues and adding features as they are ready. I don’t believe there is built-in machine learning that gets flushed by firmware update. Please tell me if I am wrong.

There is no machine learning in the normal sense in the Naim streamers. But yes the firmware code is optimised for best sound performance/balance as determined by Naim before it is released.
Usually beta releases are not optimised, and so there can be an audible shift between beta and release firmware with the latter being optimised.
The code execution sound performance optimisation is undertaken for each device, as the electronics and digital underlay varies between models.

As far as noise, when digital logic gates are operated, such as in buffers, CPU, shift registers and memory small amounts of electro magnetic noise pulses are created. This is natural physics due to the rapid change of states. When aggregated up over a digital system this creates a sequence of noise bursts, almost like a rhythm, as if you were shaking out a rhythm with some maracas. (But extremely quickly). By undertaking certain machine operations at precise times, the induced rhythm of noise, or shaped noise can be optimised to interact with the audio and clocking subsystems in a way that modulates any induced artefacts to act, as as I have been told by Naim, to almost act as tone controls.

[davidng]

I imagine it must be frustrating for developers and Naim not to have full control over dsp such that every update produce predicable, identical sound signature. Especially when users have very sharp hearing.

[Simon-in-Suffolk]

But they have full control over the DSP, which in terms of oversampling, reconstruction, and low pass filtering is relatively straightforward, it’s only a few lines of SHARC assembler code, and has been, I think, consistent since the days of the Naim DAC.
What we are talking here are the effects of interaction on audio in the analogue domain … not in the digital.
And I understand Naim have developed a tool/jig to help with the optimisation now… I guess Naim very much have the golden ears as well… at least they know how they want it to sound

[davidng]

@Simon-in-Suffolk

they have full control over the DSP, which in terms of oversampling, reconstruction, and low pass filtering is relatively straightforward, it’s only a few lines of SHARC assembler code, and has been, I think, consistent since the days of the Naim DAC.
What we are talking here are the effects of interaction on audio in the analogue domain … not in the digital.

@Simon-in-Suffolk, please excuse my ignorance and lack of knowledge. Thanks heaps for the insight. I frankly don’t know about SHARC but will do some reading. Anyway, as far as I have experienced, the differences are minuscule and haven’t bothered me.

We have done so well industrialising hardware manufacturing capable of producing in mass quantity, maintaining high quality with consistency. Software development otoh is still a very creative art.

[Simon-in-Suffolk]

You might want to look at the Naim product white papers on the ND555 and Naim DAC if still available.
The SHARC is the programmable digital signal processor made by Analog Devices that Naim use in their current digital source products.
No doubt all engineering including software engineering is often creative… I am an engineer and I can definitely testify to that… .

[Richard.Dane]

Here you go;

naim_dac_august_2009.pdf

ND%20555%20White%20Paper%20Final_0.pdf

[litemotiv]

@Simon-in-Suffolk

This reshaped noise can interact with digital clocks and analogue circuitry to produce an audible affect.
I understand a few years back Naim had pretty well managed to control this to almost act as a ‘tone control’ or eq. I understand however, despite this, it is still somewhat inexact, and results not always deterministic.

If it’s audible then in principle it should be measurable, if it’s not objectively measurable then the chances that external factors such as @davidng mentions (listening environment, temperature, humidity, air pressure or even having a slight cold etc.) will be more likely causes. We can expect Naim to do the proper measurements and release firmware that has been tested within spec, which means that any remaining audible difference are statistically more likely to be circumstantial to the listener.

[Simon-in-Suffolk]

@litemotiv

If it’s audible then in principle it should be measurable

Indeed, even if the measurements are undertaken by humans using scientific Mean Opinion Scoring methods… and that is how Naim tune, along with many manufacturers who fine tune products to suit human consumption. In my professional world we also follow standardised methods for MOS, in parallel with human sampling.

The real interesting challenge is modelling MOS, but that is a whole other topic
The Harman Curve is an interesting example of this in the audio replay world.

[Simon-in-Suffolk]

@litemotiv

which means that any remaining audible difference are statistically more likely to be circumstantial to the listener

Yes, but that is not how Naim do it… or I can definitely confirm it wasn’t how Naim did it a couple of years back, in terms of firmware tuning.
Firmware is audibly checked prior to release, and yes there can be subtle differences between firmware releases despite this.

Sure independent of this, humidity, sound pressure, listener mental state, temperature can all affect how a sound appears to us.

[litemotiv]

@Simon-in-Suffolk

Indeed, even if the measurements are undertaken by humans using scientific Mean Opinion Scoring methods…

Humans in groups do tend to display psychological group biases towards certain experiences (think shared religious experiences for instance), and the statistical sample size to reliably draw conclusions from subjective reports is likely too low on the Naim forums.

Wat could be interesting is if people submitted their subjective reports on firmware sound quality anonymously and independently from each other, so that peer influence is minimized, and then compare that with a scenario where people give their reports in a public environment such as on the forums. It would be interesting to see if a public environment would increase the number of comparable reports (better/worse sound quality), and to what degree.

[davidng]

@Simon-in-Suffolk

humidity, sound pressure, listener mental state, temperature can all affect how a sound appears to us.

[Simon-in-Suffolk]

Indeed… turn the heating up, have a glass of wine, and it’s amazing how euphoric your audio can sound

[Simon-in-Suffolk]

Well bias, and subjective bias, can invalidate results if done in an amateur manner.
We follow these methods such as ITU P800 amongst others
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-P.800.1-201607-I!!PDF-E&type=items

The AES has interesting papers on measuring emotional responses to sounds as well, using similar assessment methods.

[davidng]