my understanding of the situation is continuing to evolve. i've isolated the proper components, it's just a question of getting them in the right order.

the reinstall with the registry run removed eliminated all bleeding, but brought me back to the point where the highs are turning off and on. but, i've learned that this is not random, as i previously thought. rather, it's connected to the streaming proxy service - the broken clock.

when this service is launched, i get the full spectrum. when it's not, i get reduced highs. and, when it turns off [as it does], i get those annoying cut-outs.

but, the service doesn't launch through foobar - it only launches through cubase. again, this is explanatory, as i was noticing that cubase sounds differently than foobar. the service will sometimes stay on after i close cubase, at which point the foobar out will keep the highs - until it stops, when the highs drop. further, whether it launches with cubase or not is sporadic.

the firmware flash is no longer modifying the output, which indicates that the issue was in fact in the registry. but, it's also made it more difficult to get back to the sweet spot. the flash doesn't always work.

i strongly suspect that the point i'm at right now was the starting point; the sound is acceptable, and probably defines the differences i was noticing previously between the different hardware, and just thought was hardware dependent. it's relatively mild. but, now that i know it's not clean, i have to fix it.

the basic problem seems to be that the service is no longer connected to the devices.

but, i know that if i connect the service to the devices via the registry run on the install then i get fading.

i'm also noticing that the other card in the machine is maintaining consistency with the weak highs. in the past, i may have misinterpreted this - i may have taken the consistency as indicating both cards were working, and then concluded the output was solid, when in fact there seems to be a root problem that is affecting both cards.

there's two things i can try.

the first is that i can try a reinstall without breaking that first aspect of the clock. as mentioned before, it's only that first part that i'm certain i was reinstalling and only the first that windows is recognizing post-break. the other two, i'm just blurry about. i'll have to check to see what i get out of that - and i can do partial installs for this purpose.

if that creates the same basic issue, the next step is to put that part back in the registry run on the driver install.

if that brings me back to the bleeding, i can try and take out the entire clock break.

so, that means i'm now going beyond trying to get back to where i was and trying to fix a problem that was there the whole time but that i never noticed.

i don't think it will be much longer. i'm pretty sure i've got my head around this, now - i'm no longer taking guesses. the guesses have isolated the issue, and now i'm zeroing in on it.

i tested the issue by flashing the device and leaving it on for a reboot. if it was a firmware corruption, it should have come up clean on the reboot - because the device stayed on. but, it didn't. so, it's an error that's happening when windows recognizes the device. and, because it's not happening on the flash, it has to be the result of some kind of corrupt registry setting - because everything else would be the same, whether it's rebooting itself on the flash or being read as a device by windows.

when i do the reinstall, i'm going to try and clean as much out of the registry as i can get out of it - and i do think i can probably get this to work. but the class installer uses long strings of numbers that are difficult to track down.

i can't explain why this wasn't happening previously - except that it maybe was, and i didn't notice. which is another layer to keep in mind as i'm reanalyzing material.

the other thing is that i have a vague recollection of deleting the filters on the install a while back. so, those filters might have been gone for quite a while. i can't clearly remember. that's something i can script, and should so i don't forget.

the driver reinstall helped substantially, but it still seems a little distorted, so i'm going to reinstall a final time - i feel i have to to be sure i've actually hit the root of the problem. but i think i'm starting to finally get my head around what actually happened.

1) i think i cleared out the registry on the last reinstall, some time ago - whenever it was. spring of 2014, maybe.
2) then at some point in may i put that file back (streamci.dll).
3) on a driver reinstall (these are done from time to time, to deal with funny plugins), that screwed up the registry.
4) when i deleted the clock before, it didn't matter - because i wasn't really using it for this device. but, the combination of the driver install and the undeletion of the clock created a conflict. i suspect i should be able to reinstall the clock after i stop the drivers from entering that information into the registry.

the root cause of all of this, then, seems to be the driver install with the streamci.dll in place. i suppose i may have exaggerated something with that codec install, but it wasn't the actual crux of the problem.

it's continuing to behave poorly, but it really has to be a registry issue. i'm going to try a driver reinstall, but if that doesn't work i'll have to back up and do it again - this time inserting a wipe before the reboot, to prevent the install from completing.

on a clean sweep install with everything the way it was saved a few weeks ago, which means that the streaming proxy bit & clock are broken, it no longer bleeds. it's stable on the out. but, the out is missing a layer at the high end. it sounds like less an eq dive and more like a straight low pass, but i'm suspecting it's more along the lines of that a part of the stream is broken. it's pretty high - around 10 Khz or so. and, if you'll recall, this was the basic problem i noticed in the first place, which had me mixing higher than i wanted.

but, here's an interesting fact: i've pointed out before that a firmware flash resolves the issue. and, that's what is continuing to happen, but only until i reboot the device. it's quite strange.

in theory, i could just flash the firmware every time i turn the device on. but, that's kind of scary. if the power goes out when it's flashing, i could brick the device. and, if the issue is that the firmware is instantly corrupting, i want to think about replacing it.