Burn in process with new firmware?

[yabaVR]

I think what I'm trying to say is - people suspect Devialet , Linn or whoever of deliberately making sound quality changes when they don't mention any in the release notes, but in reality the people who coded the changes are quite probably baffled at reports of differences and probably think we're all mad, even though there could potentially be changes in SQ but caused by something the coder was not aware of and didn't intend.

+1 exactly what I would expect.

And it's the same with AO and alike. With e.g. AO you get less tasks, processes, CPU doing something and it turns out to be very sound dependent. The less the CPU is doing the better it sounds. I would expect the same with the CPU in our D's.
Perhaps this is one reason (beside others) this 7.1.3 firmware sounds so good for many of D-owners. Perhaps there are much less processes going on, the programmer worked tidy, the compiler was a better one (in any case for our ears   )...who knows. These effects are not meassured nor cared about by Devialet and I fully approve to them. It would be bottomless to optimize this task.
It's just a glitch in the matrix and we (some of us) are the loony ones hearing the glitches and even discuss them 

Thanx to thumb5 for summing up the tasks of programming. It really is complex to somebody not being in this profession.

The succeeding question for me is, what does the machinecode do on the physical plane when it sits there in the cache/memory/IC and the D is fired up?

e.g. we can switch off the standby-function in the configurator. I assume that the switch for standby (off) cuts off the process/loop of counting seconds (and therefore some transistors in the CPU are send to slumber) before the CPU has to pull a switch in the powersupply and cuts off different paths of power for different parts in the D's. Is this right or is the original process even more complex?

gui