Personally as a "systems engineer", I trust what I can reproduce. When I write code, I write tests for that code. I know I've fucked up when my tests don't pass. And when I write something that breaks in strange ways, I figure out where my tests fail.
Same thing when I'm answering support tickets for "this strange thing happened, can you figure out what broke?" I poke around, many times I have no idea what broke because I can't reproduce it. It drives me crazy. Thankfully I get the satisfaction from time to time that I do find the root cause of something. I had a good one this week, a bug in someone else's code was causing random tasks to crash. Oh wait, we're talking audio. I prefer the same philosophy here. If someone can reliably reproduce "This pair of things sound different when you change X." I want to know why, what can we measure to show a clear reason behind the change, however slight. Back to systems again. I was dealing with a system that would randomly crash, and crash hard. We poked at every single thing on the motherboards we had for testing. Eventually we had someone hand-wire probes onto some of the dimms and we booted it up with a scope monitoring the signals being sent to the dimms. We eventually found that at one point in the development of the system, a setting changed, and was using a much more noisy signaling method to talk to the dimm, and was generating bit errors. Systems can be measured, and if the measurements don't show anything, you're not looking close enough. -- SuperQ ------------------------------------------------------------------------ SuperQ's Profile: http://forums.slimdevices.com/member.php?userid=2139 View this thread: http://forums.slimdevices.com/showthread.php?t=56712 _______________________________________________ audiophiles mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/audiophiles
