Emulator

JMC4789 wrote:

Are you using libUSB (WinUSB driver) or usbdk. This isn't a regression in Dolphin exactly as it won't happen in Linux under good libUSB support.

You can try installing different drivers to see if one works better. You can also try using a faster USB port. This is a shitty situation as there isn't much we can do about it iirc.

I was using libusbk for the driver following the instructions posted here for dolphin 5.0-2352 and newer: https://wiki.dolphin-emu.org/index.php?title=USB_Passthrough I replaced the driver with Zadig. I will try to use a different driver and different usb ports and see if the results change and post updates when I get the chance.

Please do... it's one of those things where it may be out of our control, unfortunately.

leoetlino wrote:

Any chance you could load the debugging info so we can see where it's crashing?

I think we should still consider this a regression as it used to work fine in 5.0.

Sorry, I'm new to this project and just haven't quite gotten there yet. I will try to post again where it crashes after I figure out adding debugging symbols and I get a chance. Thank you for your attention on this matter.

I think this is the same problem that affects usb Passthrough in "We Sing" and "We Sing Robbie Williams" (instead "We Sing 80s" works perfectly, maybe because it has a more recent game engine?)...the problem is that Dolphin self-closes itself at random times without an error notice or pop-up, so in such case is there a way to have an error log registered anywhere?

Try using Linux, it shouldn't crash there. I'm not saying that sarcastically, it'd be nice to know for sure this is the libUSB shenanigans.

Easier said than done: other than installing a new OP, there's not even an automatic buildbot for linux...

I mean building Dolphin on modern linux is pretty easy, evne I can do it when I'm not lazy.

Also, I'm not expecting you to do it, I know this happens. It just depends on how Windows + LibUSB is feeling on a particular computer as to how well it works. It happened to me for years, then stopped happening, and is happening again now. I'll reinstall the drivers a couple dozen times and it'll start working again for a while. It's not a bug in Dolphin as far as I can tell, but, we probably shouldn't crash.

What's strange is that not every game is affected: on my system it seems that the old We Sing series (We Sing and We Sing RW) crash (self-close) randomly, while newest Wii Sing series (like We Sing 80s) and Let's Sing series don't crash...why is that happening? I mean if there's a bug in the Windows or UsbDk or Libusb driver, why only some game crash and the other don't?

InlineData wrote:

JMC4789 wrote:

Are you using libUSB (WinUSB driver) or usbdk. This isn't a regression in Dolphin exactly as it won't happen in Linux under good libUSB support.

You can try installing different drivers to see if one works better. You can also try using a faster USB port. This is a shitty situation as there isn't much we can do about it iirc.

I was using libusbk for the driver following the instructions posted here for dolphin 5.0-2352 and newer: https://wiki.dolphin-emu.org/index.php?title=USB_Passthrough I replaced the driver with Zadig. I will try to use a different driver and different usb ports and see if the results change and post updates when I get the chance.

I replaced the driver with the original default driver that was installed when the dongle was first plugged in (hidusb) and the crashing stopped. Thank you for the suggestion. I guess that it is a support issue you usbdk on windows 10. Also because this seemed to fix the issue I will not continue with other peoples suggestion thank you everyone though!

Side note in my testing I found that the microphone would not work under any driver including its default usbaudio. This includes winusb usbdk usbwin32 (I was trying everything zadig had just out of curiosity). After a couple minutes of play there would be a crash on any of these usb drivers. The setup should have been correct too usb passthrough and whatnot. I will probably make a new issue thread when I get the chance once again unless advised otherwise.

Like I said, more issues probably won't help. This is an issue beyond what anyone in Dolphin can fix. LibUSB support just sucks in Windows compared to Linux.

Well I don't think it really sucks so much, in fact a lot of games work very good and the only ones that I found not working for now are the old We Sings and the culprit must be the fact that they were designed to work only with the Logitech microphone, while newer We Sings editions (like We Sing 80s) are compatible with every usb microphone. So in this cases there must be some conflict with the exclusive Logitech usb code and I also wouldn't be 100% sure that Linux could fix that problem...

markwest76 wrote:

Well I don't think it really sucks so much, in fact a lot of games work very good and the only ones that I found not working for now are the old We Sings and the culprit must be the fact that they were designed to work only with the Logitech microphone, while newer We Sings editions (like We Sing 80s) are compatible with every usb microphone. So in this cases there must be some conflict with the exclusive Logitech usb code and I also wouldn't be 100% sure that Linux could fix that problem...

I agree. Coverage seems to be pretty good. This is pretty much the only game I had trouble with personally. It would be nice if I could get it to work though without having to install Linux.

Side note: the USB Microphone I'm using is an original Rock Band microphone (Model Number: A-0234A VID: 046D PID: 0A03) so unfortunately I think that isn't the issue. I was going to do a build of Dolphin on Windows that way I could have debugging symbols to see where it crashes. I will post them later if anyone is interested. Sorry it took so long been busy.

I actually know why it fails on Windows... the USB Microphones (and camera) use a feature that isn't well supported. I forget what it's called, but, Microphones and Camera only consistently work on Linux.

InlineData wrote:

InlineData wrote:

markwest76 wrote:

Well I don't think it really sucks so much, in fact a lot of games work very good and the only ones that I found not working for now are the old We Sings and the culprit must be the fact that they were designed to work only with the Logitech microphone, while newer We Sings editions (like We Sing 80s) are compatible with every usb microphone. So in this cases there must be some conflict with the exclusive Logitech usb code and I also wouldn't be 100% sure that Linux could fix that problem...

I agree. Coverage seems to be pretty good. This is pretty much the only game I had trouble with personally. It would be nice if I could get it to work though without having to install Linux.

Side note: the USB Microphone I'm using is an original Rock Band microphone (Model Number: A-0234A VID: 046D PID: 0A03) so unfortunately I think that isn't the issue. I was going to do a build of Dolphin on Windows that way I could have debugging symbols to see where it crashes. I will post them later if anyone is interested. Sorry it took so long been busy.

For those that might be interested in a more helpful screenshot with debugging symbols please see the attached screenshot. This crash occurred with me using the usb microphone I described earlier approximately 8 mins into gameplay. I don't know if it is something that could be fixed. It does seem to be something related to libusb as suspected.

I'm not too familiar with libusb or the design of dolphin's emulator being really new here but if I may pose a possibly really dumb question: could this exception be handled? I'm imagining this problem is related to dolphin polling on data that isn't ready because of issues on libusb's end. Assuming that libusb eventually gets back on track (polling data) could we catch this exception send a temporary value to the emulator while the data isn't present from libusb and then resume once libusb has caught up. This would most definitely probably be a kludge but might be the only thing that could be done without libusb being fixed. I don't think the libusb team would fix it because it seems like most the work on those projects stopped 2 years ago. Sorry I though I would just pose this question just in case it was productive. If it is really really dumb you don't have to dignify it with an answer XD

Sorry just catching myself with a mistake: when I meant catching the exception I mean check if the list->next was null and doing something appropriate to handle that case

JMC4789 wrote:

I actually know why it fails on Windows... the USB Microphones (and camera) use a feature that isn't well supported. I forget what it's called, but, Microphones and Camera only consistently work on Linux.

Isochronous transfers. They seem to cause a lot of trouble in libusb on Windows.

InlineData wrote:

Sorry just catching myself with a mistake: when I meant catching the exception I mean check if the list->next was null and doing something appropriate to handle that case

That's not possible. If you look carefully, you'll notice that this is entirely in libusb code. It's crashing in libusb code. Of course, it's still possible that Dolphin is using libusb wrong, but this has all the signs of being a problem in libusb especially when you consider that the same code works without any issues on Linux and also on Windows as long as isochronous transfers are not involved.

Could you also show the stacktrace, so we can see what it was doing right before the crash?

I wanted to report that as I said microphone work perfectly on Windows 10 with every Let's Sing game and every We Sing game except We Sing and We Sing Robbie Williams that are the only ones that support only Logitech microphone, so according to your words in those two games isochronous transfers should be used while in every other game not…

Could you tell me how to get a stacktrace when Dolphin self-closes itself without any error messages?

Well, all microphone and Wii Speak titles use isochronous transfers, but there are several different interfaces and the games themselves may be setting up transfers differently. It's hard to tell what the issue is without a stack trace, but I'd bet it's related in some way to isochronous transfers considering we've had so many issues with them.

You need to launch Dolphin in a debugger (since you're on Windows, use Visual Studio).

Sorry, I'm not a real Visual Studio expert (in fact I've never used it until today :-/), so what option/path do I have to choose in Visual Studio to launch Dolphin?

Open the Source/dolphin-emu.sln that is in the Dolphin git repo, then press the Local Windows Debugger button (with a green play icon) in the toolbar at the top of the screen. For performance reasons, you may want to change from debug build to release build before you press Local Windows Debugger, which can be done in the same toolbar.

JosJuice wrote:

Open the Source/dolphin-emu.sln that is in the Dolphin git repo, then press the Local Windows Debugger button (with a green play icon) in the toolbar at the top of the screen. For performance reasons, you may want to change from debug build to release build before you press Local Windows Debugger, which can be done in the same toolbar.

Don't know if it's still necessary, anyway I've tried as you wrote and got following errors:

Error MSB3073 ""%windir%\Sysnative\cscript" /nologo /E:JScript "make_scmrev.h.js"
:VCEnd" con codice 1. SCMRevGen C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets 128

Errore C1083 'Common/scmrev.h': No such file or directory
#include "Common/scmrev.h"
^ Common d:\emulatori\gamecube-wii\dolphin-master-source\dolphin-master\source\core\common\version.cpp 9

Error C1083 'Common/scmrev.h': No such file or directory
#include "Common/scmrev.h"
^ Core d:\emulatori\gamecube-wii\dolphin-master-source\dolphin-master\source\core\core\configmanager.cpp 26

Error C1083 'Common/scmrev.h': No such file or directory
#include "Common/scmrev.h"
^ UICommon d:\emulatori\gamecube-wii\dolphin-master-source\dolphin-master\source\core\uicommon\autoupdate.cpp 15

Error QTDIR not set or non-existent (pull the submodule?) Dolphin D:\Emulatori\Gamecube-Wii\Dolphin-master-source\dolphin-master\Source\VSProps\QtCompile.props 68

I know it's been a while, but would you like to try some changes? We fixed some USB bugs, both on Dolphin's end and libUSB's end.

For this, you must NOT use usbdk, instead, use zadig to install libusbK (which has working isochronous transfer for the most part,) for the microphone and anything else you think may be crashing.

Then use this build (which will likely not support usbdk anymore) - https://dl.dolphin-emu.org/prs/pr-8070-dolphin-latest-x64.7z

It fixes microphone crashes in Glee, Your Shape, American Idol Encore, and others on Windows for me.

Thanks, for me PR8070 fixes the problem

I tried to get PR8070 working. I used Zadig 2.4 to install libusbK (v3.0.7.0) onto the Logitech USB Microphone 046d:0a03. Then I tried to run Rock Band. Unfortunately, no microphone was recognized. Are there any other special steps to get this to run? I also tried to add it to the Whitelisted USB Devices under the Wii tab in settings. usbdk isn't currently installed on this system. This is a Windows 7 machine. I can't uninstall usbdk on my main Windows 10 machine without blue screening lol.

You need to show all devices (I think it's parent/composite) and replace the driver on the composite device.

Now that PR8109 has been merged, I think this issue can be closed...

I'd prefer keeping this open until PR 8070 is merged, as that PR is still required to fix some libusb crashes on Windows.

@JMC4789 thanks for the advice. The switching the driver on the composite device fixed it.

I tested for 2 songs in Rock Band on vocals with PR 8070 and it worked flawlessly. Thank you to all of the people that worked on this! :D

https://github.com/dolphin-emu/dolphin/commit/aca46b11f869a31be3e98af756c4fdfe5c6ed22a