-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WRS] Caster v 0.4.9 does not initialize #68
Comments
This is one of the errors I got when I tried to run Caster on a virtual machine. I just updated sample.py so that it should be able to run on its own, independently of Caster. sample.py is pure Dragonfly. Would you mind running it and telling me what happens -- if it runs and if you can use the commands from it? If it works alright, we can rule out the problem being anything about your Dragonfly setup. |
This issue stems from dragonfly not being enabled to initialize WSR. WSR could be sensitive to suspend resume with windows or virtual machine. Normally when launching castor or _sample.py automatically launches WSR. I noticed when all these issues were present that WSR would not start manually through windows explorer. Restarting the computer WSR, Caster, and dragonfly tested though _sample.py functions as expected. This leads me to believe that WSR outside of dragonfly or castor has a bug. A bug that is most likely related to WSR and windows waking up from hibernation or sleep mode. See if rebooting your virtual machine through windows then try WSR. I'll keep looking for a method to make it reproducible. This is the output when I tryed to initiate the file you suggested above before the reboot. C:\Windows\System32>C:\Users\user\Desktop_sample.py C:\Windows\System32> |
Ah, the old reboot cure-all, haha. I'm glad to hear there is such a simple fix, though I too would like to know what this is about. I can reproduce this every time on my virtual machine installation (VirtualBox, Windows 7), but I still have no idea what's happening. Your discovery about sleep mode is a new piece to the puzzle. |
Also, I suspect that your guess is correct: that WSR glitches out somehow, both with a virtual machine and with sleep mode. I have rebooted my virtual machine, but that doesn't seem to help. |
There's another very plausible parallel between Virtual box and my current setup that could also be the source of the issue. Put simply virtualization. More specifically Virtualization of the soundcard or sound source or the possibility the WSR 'see' the sounds source as invalid but windows itself does not. I use and NoMachine to remote into my desktop environment to utilize DNS on my windows tablet. NoMachine forwards the mic audio over the Internet or network to the desktop. There's a delay but tolerable. For WSR, DNS, and NoMachine I use an android app (WO Mic) and it's windows client to stream audio from my android phone to Tablet or PC. That way I can use any headset (Ear buds with a inline mic atm) and manage incoming calls. In addition, it completely bypasses the tablet or PC's sound system. Which in many cases such as a cheap sound card or I/O shielding can be the source for poor speech recognition. WO Mic Client occasionally freezes. I'll have to see if I experience the bug with WSR right before or after that Issue. Its drivers not digitally signed and written by android dev. Dubious quality... There's only two apps that perform the same function in the google play store as WO MIc. DNS Remote microphone app which only allows you to use your built in microphone on the cell phone and only works with dns. In addition it's buggy requiring restarting DNS and the DRM app. I have been unsuccessful in finding alternative outside remote control apps. That might sound a little complex but the bug might be from WSR not properly Initializing with some virtualized inline sound sources or 'invalid' sound sources. That being said to test my theory install NoMachine on the virtual machine and another computer. I had not had issues with NoMachine virtual sound card/source. Remote in to the virtual machine using NoMachine and make sure Virtual box Windows default recording source is set to NoMachine mic. Then start WSR to test. This should be a definitive test to determine whether not virtual box sound card/source emulation is incompatible with WSR. On an unrelated note, Would you mind connecting over voip from time to time to discuss Caster? |
Let me make sure I have this procedure down:
No, I wouldn't mind connecting over VoIP. I don't think Github has a private messaging system, so contact me through this and we can set up the details. |
That is a correct procedure. |
BTW, I haven't forgotten about this. I'm still not quite up to the point of having Dragon working on a virtual machine, but I get a little closer every weekend. |
The text was updated successfully, but these errors were encountered: