Burn in process with new firmware?

[thumb5]

None taken

[yabaVR]

0k. To be more precise.It's not the firmware in special I'm up to.

I'm interested in the aspect, what does a virtual line of code (software) do on the physical side (inside the lC ).
My uneducated view is that it (this line of code) pulls a switch, so the signal takes another path/procedure in the IC?

Software to my understanding is the programers virtual view to solve a problem or invent a feature, but at some point it has to become physical. How does this happen. If this does or does not affect sound is not of my interrest to discuss here...it would be endless 
Perhaps my fault to have chosen the wrong topic for this thread but I didn't know how to get in short enough otherwise.

And it might be of interest for others to get only an idea of how our D's are functioning because Devialet claims to solve many audiophile problems in software.
gui

[Hifi_swlon]

It's complicated that's for sure! Fully understanding how code humans write turns into code directly used by the CPU, and then how the CPU itself works (especially a modern one) right down to the physical atomic level is probably a lifetimes study. I only touched on it indirectly, and don't know it as well as I used to, but would suggest a bit of Wikipedia and google and branch out from there.

Perhaps someone here is that expert and can explain it succinctly from top to bottom. I'd be interested too.

https://en.m.wikipedia.org/wiki/Machine_code

[Rufus McDufus]

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.

[Hifi_swlon]

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.

[thumb5]

At the risk of being pedantic (not for the first time!), I think the discussion is going a bit off topic here: it seems to be veering towards differences in sound quality between different versions of firmware whereas gui's original post was about variation in sound quality over time with a given version of firmware.

Let me jot down a few quick notes about the typical process for building and updating embedded software.  This will miss out lots of details which depend on the application/market, hardware, tools, etc. but hopefully could be a basis for discussion.

Embedded software is normally written either in assembly code or a (so-called) high-level language such as C or C++.  Assembly code means that the programmer must write the program using the instructions defined and implemented by the processor itself - ARM, SHARC, Intel x86, etc. - and is completely in charge of how the processor registers and memory are used.  By contrast programs written in C or C++ don't depend directly on the exact processor hardware and can be more easily made to run on different processors.  For most general-purpose embedded systems, high-level languages are used wherever possible.  But for an application like digital signal processing, especially on a processor like the SHARC, assembly language might be more often used since it can give higher performance or access to special features of the processor that can't be used from C/C++.  In the case of the Devialet I'd expect all the DSP-type software (including SAM, tone controls, volume control, etc.) to be written in assembly language but the UI, configuration, etc. to be in C.

Once the program is written in source (that is, human-readable) form, it has to be translated into machine code -- that is, the binary code that the processor can actually execute.  For assembly code, this is done by a software tool known as an assembler.  For a high-level language this is normally a two-step process: the high-level code is first translated to assembly language (by a compiler) and then assembled.  The compiler can be a very complex tool as it tries to optimise the assembly code it produces to give the best performance and/or smallest memory footprint (or more usually some compromise between the two).

Most embedded software will be built from more than one source file, which may include both assembly and high-level code.  Once these have been translated to machine code, they can be linked together.  At this point the programmer defines where in the processor's memory the program code and data will reside.  This is done by a tool known as a linker.  The linker produces a binary version of the program -- more or less an image of what needs to be loaded into memory so that the processor can run the program.  This is just a (very!) long series of 0s and 1s, organised into units of (typically) 8, 16, or 32 at a time.  For example each unit could represent a processor instruction or some data, both of which would be stored in memory.

Up to this point, the software has been built on a development system which is normally a PC -- that is, not the target embedded system.  The output is an image of the program code and data, sitting in a file on the development system.  The next part of the process is to load the program image into the memory of the target system.

The processor in the target system will automatically start reading instructions from a pre-defined place in memory when it is first powered up.  That means the program code and data must be stored in some kind of non-volatile memory so that it's always there when the system starts up, without having to be loaded by hand each time.

These days, the program image is normally stored in "flash" memory -- more or less similar to what's inside a USB memory stick or an SD card, but either built into the processor itself or directly connected to it.  The program image produced by the linker needs to be taken from the file on the development system where it was built, and somehow installed in the flash memory on the target system.  One way to do this is to use a special hardware connection on the target system which allows the flash memory to be programmed using special tools running on the development system.  This is often how the first firmware gets loaded during production on brand new hardware.

The program loaded on the target system might include code to update itself after production.  That's the case for Devialet amplifiers, of course: the firmware can recognise when an SD card contains new binary files, and can re-program its own flash memory with the updated firmware.  Then when it re-starts, it's running the new firmware.

[Wrote that in a bit of a rush, so might come back and edit or fill in detail later...]

[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

[thumb5]

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?

Thanks gui.  I'll extend or follow up that post with more about how the processor interacts with memory to run the program as soon as I get chance to put my thoughts in order.

[thumb5]

[The long-overdue follow-up to post #16...]

When it's powered up or comes out of a hardware reset, the processor starts fetching instructions from a known location (address) in program memory.  This might be non-volatile memory built into the processor itself, or external memory that's been programmed by the system manufacturer.

This first set of instructions might be the complete program that the system runs indefinitely, or it might be a boot loader that loads the "real" program into writable memory (RAM) and then starts running it.  In some systems the initial program might copy itself from the non-volatile memory into RAM for performance reasons since RAM tends to be faster to access than flash memory.  In other sytems - usually simpler ones - the program runs entirely from the original non-volatile boot memory.

Once up and running, the processor will be continually accessing memory both to fetch instructions and to read or write data as directed by the program.  The instructions and data might or might not be in the same memory device, depending on the processor architecture and system design.

When the processor accesses a location memory it presents an address to the memory device; this could be the address of an instruction in program memory, or of a variable in data memory.  The address is typically a 16-, 24- or 32-bit binary value calculated by the program.  It uniquely identifies a particular location in memory.

The memory device accepts this address and uses it to find the value stored in memory.  The way this is done depends on the memory technology and how its organised. For example the address is often broken into two parts which are used as "co-ordinates" of a two-dimensional array.  Where they intersect is the memory location (word) being addressed.  If the processor is reading, the memory returns the value in this memory location to the processor; otherwise, the memory accepts the value being written by the processor and stores it in the addressed location.  In both cases the value is transferred on a data bus which is typically 8, 16, or 32 bits wide.

The actual memory technology used for storing programs might depend on whether it's on-chip or off-chip.  Off-chip memory will almost certainly be a variant of flash memory these days, but it might be one of two main types: NOR flash or NAND flash.  NOR is easier for the processor to use as it directly addressed and word-oriented (like traditional RAM) and is usually assumed to be error-free.  NAND flash behaves a bit more like a disc drive: it supports larger amounts of storage, is block-oriented and can have errors, though it usually also contains error correction mechanisms.  Processors can't normally run programs directly from NAND flash unless they include special "execute in place" hardware.  For on-chip program storage, either NOR flash or factory-programmed ROM is normally used.

As well as non-volatile program memory, the system also has to have normal read/write memory for storing variables and data that change as the program runs.  Again there are choices here: the most likely technologies are either static RAM (SRAM) or synchronous dynamic RAM (SDRAM).  SRAM is much simpler to work with and has lower power consumption, but gets expensive for large amounts of storage.  SDRAM is the memory that's usually found in a desktop or laptop computer: it supports larger amounts of memory but is power-hungry and complicated.

There is a problem: memory devices, especially flash memory, usually have quite long access times compared to the rate at which the internal parts of a typical modern microprocessor can operate.  If the processor always had to access external memory for each instruction fetch or data access it would run very slowly.  This is the so-called "memory bottleneck".  To overcome this, processors often make use of caches (very fast, on-chip memories) to store frequently/recently-used instructions or data.  There may even be multiple levels of cache, the fastest and smallest being integrated on the chip, and slower/larger external (level 2) cache outside the chip.  The cache(s) will be designed carefully to suit the processor and there are many subtly different design approaches.

Although using caches can improve the performance of a system it can also make it more variable and hard to predict.  For example in a system that has to respond to external events like arrival of data from Ethernet or USB, the code that runs to handle these events can "knock" out of the cache other code or data that might be involved with audio processing.  In a system that wasn't designed very carefully that could sometimes cause the audio processing to miss samples depending on the exact timing of things happening in the outside world.

The SHARC processor (used in Devialets) has a Harvard memory architecture so instructions and data live in separate memories which operate indpendently in parallel.  That helps to reduce the effect of the memory bottleneck, but caches are still used.

I haven't poked around inside a Devialet to find out what type of program and data memory it uses - that would be an interesting exercise.  Maybe Antoine knows already!