Gilden00

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.

I'm sure that's likely the case in many situations, but I don't believe that was the issue here. I don't have the hardware anymore, so I can't test it to see, but here's what I recall: The sample rate of the input had no effect on the issue at all. For instance, if both input and output were set to 48KHz, the issue was present. If the output were set to 44.1KHz, the issue was completely gone. Additionally, while the 44.1KHz option was available for the input, I couldn't get it to change off of 48KHz. I would change it to 44.1KHz, apply changes, and then reopen the screen and it would be back at 48KHz. If the input/output sample rate being different were a problem here, then the fix I suggested would actually exaggerate the problem since output would be 44.1KHz and input would still be stuck at 48KHz. I also believe that Windows automatically resamples to match the output device, otherwise we'd have nonstop sample rate issues across media that are recorded at different sample rates. To further that point however, I know that 48KHz vs 44.1KHz recording wasn't the issue. I used my mic online all the time, so I would always be told as soon as the deep voice issue started. That means that if it was a sample rate issue between input and output, changing my output sample rate wouldn't fix the problem for other people (which it did in this case). My current setup uses 48KHz on both the input and output and I don't have the deep voice issue. If the sample rate were really the problem, then it would sound fine for me but still be messed up for them (assuming their output were still set at 44.1KHz, and almost everybody hasn't changed their audio setup), would it not? I believe this is 100% a driver issue. In my experience, this issue only occurs in these situations on this hardware. I reported the issue to Line6 when I first encountered it and they just ignored me because "the software I used isn't officially supported". To be clear, I used Audacity to hear the effect for myself and the effect was heard through every other software I tried (Discord, Google Hangouts, and OBS are the ones I can think of off the top of my head). While Audacity may not be industry standard for anything, it is still common place enough that you shouldn't just ignore that issue because of it, especially when it's observed in so many other applications AND report by many other users (I linked to multiple forum posts in the ticket I submitted). I liked the UX2, but because I had this issue for so long and support refused to even talk to me about it, I switched to different hardware and have been problem free ever since. I honestly hoped that they would eventually do something about it, but considering that it's been over two years since I posted a solution and over four years since I first started experiencing the problem, I'm incredibly disappointed to see that people STILL have this issue. Just some additional points of clarification: This occurred for me when using the UX2 as my input device. The live monitoring through the UX2 sounded perfectly normal regardless of the sample rates used in Windows. The issue was present regardless of whether or not I used the UX2 as my output device, and changing the sample rate of the UX2 output device fixed the issue even when I wasn't using it as my output device. Some of the specifics in this post may be a bit off, this was from 2 years ago and I don't have the hardware anymore.

Had this same issue for a while, and changing the sample rate on the input didn't help. Found a solution today that I wanted to share. tl;dr: (For Windows 10, can't confirm on other systems) Change the UX2 output device to use 44.1kHz instead of 48kHz or vis-a-versa and see if that fixes your problem. On Windows 10, changing the recording frequency of the input device didn't do anything for me. As odd as it sounds though, changing the output device from 48kHz to 44.1kHz DID fix the problem. Not sure why (driver issue perhaps?), but making that change fixed the issue of my voice being super deep when using the UX2. Confirmed the fix in a voice call with someone where I switched the setting back and forth. Whenever my UX2 output device is set to 48kHz, the input device sounds super deep, but when the UX2 output device is set to 44.1kHz, the input device sounds perfectly fine.