Before I dive into this, I wanted to say one thing. Since it can be difficult to interpret tone of voice in online discussion, I wanted to make it clear in no way am I upset or angry with you or Line6. At this point, I'm more interested in having a real conversation about the issue and hopefully getting a real resolution for anybody still using the UX2, because I do 100% believe that this is a driver issue and not user error. If at any point you don't want to keep up with this, feel free to duck out, this is just a curiosity for me.
"Most likely the default sample rate was set at 48k for the device, thats why it would 'revert' when you re-opened the window." Are you saying that, for example, if the default is 48KHz it will display 48KHz instead of 44.1KHz even if 44.1KHz is what is actually selected? That's not how the settings menu works in Windows 10. If you're on Windows you can confirm for yourself in Control Panel. The factory default value is what's selected initially, sure, but anytime you open that screen, it will show the current value by default. It did that with the UX2 output device and my other input devices (both at the time and now), the UX2 input device is the only one that wouldn't save the setting.
"When you changed your output sample rate (to the same as input) - others heard your sound correctly, right?" No, that's not correct. Let's ignore what it showed in that settings screen and assume whatever I selected was actually used (I remember testing this at the time, I constantly switched between 44.1 and 48 on input trying to figure out the issue). There are 4 cases here:
Input Rate | Output Rate |
44.1 KHz | 44.1 KHz | No issue
44.1 KHz | 48 KHz | Deep voice
48 KHz | 44.1 KHz | No issue
48 KHz | 48 KHz | Deep voice
Keep in mind that it always showed 48KHz in the settings menu for the input device, but having the output set to 44.1 is what would fix the issue.
I'm going to assume you know more about sample rate than I do (because you almost certainly do), so perhaps you could answer a question for me here:
I understand (or I think I do) why the deep voice issue would occur if the sample rate were higher on the input than the output (or is it the other way around?). Shouldn't the opposite be true if the sample rate were lower on the input than the output and have a higher pitch?
"THAT doesn't make sense, most likely you were changing the sample rate IN the software. How were you monitoring? - what were your speakers or headphones connected to?"
I always changed the sample rate in the Windows Control Panel. I played with the sample rate in Audacity and didn't notice any difference. Also worth noting is that this issue occurred in some software where you can't change the sample rate, specifically Discord and Google Hangouts.
Headphones were plugged directly into my on-board audio (live monitoring was not used with on-board) instead of through the UX2 monitor port (again, microphone always sounded correct in the live-monitoring). It's a matter of if I was using the UX2 output audio device or the on-board output audio device during playback. Playback was of audio recordings. If I recorded with the UX2 as my output device or the on-board as my output device had no effect on the issue. Microphone was always connected through the UX2 for testing. Honestly, I don't see any reason why it should have an effect on it. The output device will ONLY effect the OUTPUT, it has no connection to the input or the recording. I'm aware that runs counter-intuitive to what I'm suggesting the issue is, but that is simply because the UX2 input and output run off of the same driver, and I'm suggesting it's a driver issue instead of a sample-rate issue (because all the evidence I have points towards it being related to, but not directly caused by sample rate).
I'm going to have to disagree with you on how 'correcting' the output sample rate should fix what other people hear. In absolutely no way should the output device effect what is recorded by the computer. Playback makes 100% sense, sure, but I should be able to take a microphone and record audio with no output device at all and the recording still sound fine when played back later. The recording comes 100% from the input device, neither Windows nor the application being used to record the audio cares what the output device is or how it is configured when pulling data from the input device.
The best explanation I can come up with as to what's happening here is this:
The input sample rate setting isn't used at all (this explains why the input sample rate isn't saved). Instead, Line6 may have tried to prevent sample rate mismatches by having both the input and output sample rate controlled by the UX2 output sample rate. Not a bad idea IMO, but if that is the case, then there must be a driver issue that is allowing this issue to occur. My suspicion would be that the UX2 records at the configured sample rate and windows assumes it's being sample at 44.1 - regardless of what is actually configured. Either that, or the issue could be flipped and the UX2 is always sampling at 44.1 and Windows assumes it's coming in at the configured sample rate - causing an issue when it's configured at 48. In either case, switching the output sample rate to 44.1 would explain why it suddenly starts working consistently.
As was noted early on in the thread, this issue wasn't always present and would appear over time. A restart could fix the problem but didn't always, likely because the UX2 didn't fully lose power. The inconsistency of the issue and its likely hood to appear over time even when settings were not changed between when the issue wasn't present and when it appeared suggests an issue with either the hardware running for long periods of time or there being a driver/software issue when used for an extended period.