syotani

4.2.7.6 Drivers ceased to function after a few hours of playback using Firefox Flash plugin and Media Player Classic. All subsequent attempts to playback caused the host application to freeze, forcing the use of Task Manager to end task. Rebooting was the only solution. I shall revert back to 4.2.7.1 drivers if it occurs again.

4.2.7.6 Drivers: All sample/bit rates in Control Panel applet are now working for default playback and recording settings. No other issues to report.

Here's some more straw-clutching things for desperadoes to try: 1) Only have the UX2 connected to a USB 2 port. USB 3 ports will typically be coloured blue. 2) Check your motherboard manufacturers website for updated Windows 10 drivers for chipsets and USB. If you don't know your motherboard make/model/chipset then you can use CPU-Z to get this information. 3) If your motherboard has no updated drivers, and you have an Intel chipset, then try the Intel Chipset Update Utility (ignore the fact that it does not show support for Windows 10 yet). You can also try the Intel Driver Update Utility. 4) If your motherboard has no updated drivers, and you have an AMD chipset, then try the latest AMD chipset drivers. 5) Open Device Manager, expand Universal Serial Bus controllers and determine which USB Root Hub your UX2 is connected to and uninstall the hub. Reboot and the hub will be detected and drivers will be reinstalled. 6) For good measure you can also make sure power management is turned off on that hub.

For those who don't know the thread: OS: Windows 10 Pro 64bit Device: Pod Studio UX2 Drivers: 4.2.7.1 On my system the UX2 works for both recording and playback in all apps. No unplugging, rebooting or other messing around. Apps that don't let you change sample rate use the default settings made in the Control Panel applet: 48000Hz, 16 bit. I have no other Line 6 software installed besides the drivers, which were downloaded from here. The advanced tab becomes unavailable if the Line 6 driver is active. Simply opening the Control Panel Recording applet activates the Line 6 Driver: If I disable the UX2 for recording, wait a few seconds, then enable it and open properties before the driver has activated I can access the advanced tab: The same is true for playback, if the UX2 is not actively in use the driver is inactive and the advanced tab can be accessed: If the UX2 is actively playing back sound the driver is active and the advanced tab can't be accessed:

Wow, stellar progress, they've moved on to repeating what I've been saying for weeks! Yes, I posted in this thread, a while ago, that I have WASAPI (Exclusive Mode) drivers working in Reaper (latest version).

^^^ LOL! Even though I'm one of the few (only one?) who has the UX2 continuously 'working' without problems (albeit restricted to 48KHz\16bit for apps that don't have any option to change it), this is now getting to the point of ridiculousness. It's been over 4 weeks since the Windows release build was made available. Line 6 need to get their lazy backsides into gear and put out some working WDM drivers. They are still listing the broken 4.2.7.1 drivers from 2013 as Windows 10 drivers, unbelievable!

For reference, these are the drivers I'm using:

No worries. That was a cumulative update. SR1 is supposed to have major fixes for all the upgraders with problems plus some new features.

For the record, I'm running the latest Audacity, 2.1.1, without issues. MS is rolling out a major update, going by the name of Service Release 1, starting tomorrow. Let's hope this will sort out some of you out. Oh, and my thought for the day is this: Right click on the Start button Select Command Prompt (Admin) Type: sfc /scannow Hit ENTER It will probably take a while to run. What it does is repairs/replaces corrupted system files and configurations. It usually clears up a ton of problems with Windows 10 upgrades and installs.

OK, so I've hacked the crap out of the streamlined Win 10 box that I've been testing the UX2 on. It would be impractical to go through all the Microsoft and Windows things I've disabled, removed, configured, etc. If none of the previous things I have posted have worked for you then you may be heading into 'clutching at straws' territory. So, it probably won't hurt if I just start posting the tweaks on my box that might have some relevance, as they occur to me. For the record, I'm running a clean install of Windows 10 Pro 64bit, 4.2.7.1 drivers and Pod Studio UX2. Here's two, disable app access to mic and disable background apps.

Good man, I withdraw my previous aspersions... ;)

It appears to have been removed. Shady behaviour from Line 6 or what?

So, most of you lads are still having trouble getting the mic/input working with basic Windows apps like Skype, Mumble, TeamSpeak, Audacity, etc. Yet, I've got it working on mine. Audacity works with the MME, DirectX and WASAPI drivers. The only other significant configuration differences I can think of is that I have all my USB ports 'selective suspend' and 'allow Windows to power down' settings disabled in Device Manager and Power Options. But, perhaps the biggest difference is the following. Have you noticed that when booting up after shutting down Windows 10 it's significantly faster than restarting? This is because when starting from the PC being off Windows 10 uses an accelerated method called fast startup. It basically stores various parts of your machine's memory state in a hibernation file and loads it when you turn on. This is faster than loading the drivers and other system files individually as is the norm. On my system I disabled hibernation, and consequently fast startup, because I never use it and it leaves a large file (hiberfil.sys) on the disk. I did this by opening a command prompt and typing: powercfg -h off You may not want to do this, so instead you may want to just try disabling fast startup via the Control Panel: This may be connected with gl0ry's boot issue? Let us know if you have any success with these tweaks.

They've just tacked 'Windows 10' on to the list, of OS supported by the old drivers, since Windows 10 was released. And as my previous posts outline, they do partially work with Win 10. The final build has been available for three weeks now, which is more than enough time to release some fully working drivers. Despite appearances to the contrary, it ain't rocket science.

If you're stunned that drivers were not available for pre-release builds then you must have little experience re software development. As part of the Windows Insider Programme I've been receiving Windows 10 builds for the last 10 months. And the vast majority of hardware manufacturers have been developing and releasing new drivers throughout this period. The final Win 10 Public Release build was available 2 weeks before public release. And regarding Line 6 saying the 4.2.7.1 drivers support Windows 10: