Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Burn in process with new firmware?
#15
(15-Oct-2016, 09:41)Rufus McDufus Wrote: Good post Hifi_swlon - this is a complicated area and I think it might be worth stressing a lot of the potential sound quality changes could be actually unintentional and nothing to do with the actual code changes (unless of course the change is actually intended to affect sound quality).   Even something simple as making a loop (say a counter) execute more or less efficiently may (I'm guessing here) utilize cpu more or less and also affect the power profile.   I have coded embeddded devices & used various low level languages but a long, long time ago, but I suspect a lot of this hasn't changed that much apart from the method of coding becoming more sophisticated (and therefore from a low level point of view less within the control of the coder?).
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.

Having said that I'm particularly poor at hearing changes between firmwares anyway! I tend to hear much bigger differences, say, regarding how long the Devialet has been switched on or possibly other factors.

I guess there's also the chance that Devialet make changes (say maybe optimisations to reduce temperatures or just tidy up code), which directly affects the sound and shows up in their measurements, but they chose not to tell users as they don't want to announce it as a feature or get into why they did it. Maybe they can't get back to a certain sound once they've made several iterations of change? The extra power, SAM revisions etc, all have to be slotted in somehow and compromises have to be made.

I guess the only way to be sure is to design your own programmable DAC and look after the firmware yourself. It must be pleasing (and/or possibly torturous) for someone like Vincent at totaldac to think a new firmware sounds a bit less analogue than a previous, and tweak the code to make it right. Actually someone like him could probably give some real insight here (maybe it just never happens like that?) but haven't come across any posts of his anywhere.

I guess what we're asking is several things. Could different code (optimisations etc) change the sound, which I guess is yes. Could just recompiling the same code without any changes change the sound - with the CPU maybe addressing different parts of RAM or whatever, I suppose you have to say possibly, at least for it happening at some level even if we can't hear it. Would that new firmware and changes to RAM or cache pathways have a burn-in? Well, I just don't know. I'd imagine a CPU thrashing through millions (or billions) of instructions a sec would burn in pretty quickly.

>>> 1st Place Award: Devialet, last decades most disappointing technology purchase.  <<<

Reply


Messages In This Thread
Burn in process with new firmware? - by yabaVR - 12-Oct-2016, 17:30
RE: Burn in process with new firmware? - by Hifi_swlon - 15-Oct-2016, 10:15

Forum Jump:


Users browsing this thread: 1 Guest(s)