cfraser wrote: 
> ^ lol, I forget why I even said that now. I guess it's obvious you'd
> need a proper/good logic analyzer to monitor an actual design. I was
> probably thinking along the lines of the differences between running
> slightly different code is sufficiently "significant" that it can be
> detected at some distance without any physical contact with the
> computer. Never mind close up. IOW, there ARE physical differences
> manifested when you run different code. This isn't an opinion (for those
> who don't work in the biz).
> 
> Without knowing the architecture of the SBT processor etc. I couldn't
> even begin to guess. (I have a lot of ARM development boards here, maybe
> one is similar enough to give me an idea...) But I'm telling you, unless
> you intimately know how code/data is fetched and executed (caches?? and
> their operation), you can't begin to guess what effects an apparently
> minor code change that's logically identical to the previous code might
> have. Chips are designed with limitations. You exceed a limitation by
> (e.g.) one byte and the code may have a completely different execution
> signature. Rather cool to watch on the logic analyzer.

You are missing the point here - we are only discussing cases where I
believe there is no change to the active code being run - i.e. changes
being claimed to make a difference are ignored in terms of the code
running.  I agree any changes to the code running could impact at least
cpu/memory related noise on the power rails or ground plane.  However
the debate is only for the cases where there is no change to the active
code running - and hence this can't be the case.

In this specific case, the difference between 0.6 and 0.7 is something
like:


Code:
--------------------
    
  resampling = false
  
  openOutputDevice()
  
  if setSampleRate() == false then
  closeOuputDevice()
  openOutputDeviceWithResampling()
  resampling = true
  end
  
  if resampling then
  bufferSize = FIXEDSIZE      # this is the new path added and only gets 
reached if the device failed to set the sample rate without resampling
  else
  bufferSize = userDefinedBufferSize
  end
  
  setBufferSize(bufferSize)
  
  debug(alsaSettings)            # print console log of active buffer settings 
being used 
  
--------------------


Please see post #68 and my git repo for the full code.  The point is
that the binaries are traceable back to the code changes shown and
unless you can show that the resampling case is being triggered (which
we need to fix if it is), then the code is following the same path as
before and this can't impact the running code.


------------------------------------------------------------------------
Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=94855

_______________________________________________
audiophiles mailing list
audiophiles@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/audiophiles

Reply via email to