You are here
Home › Forum home › VirtualMIDISynth › Bug reports › Error occurred opening output device for MIDI device VirtualMIDISynth#1 ›Error occurred opening output device for MIDI device VirtualMIDISynth#1
Please let our ADS show!
This sites offers only FREE software and it's supported by a few advertisement boxes (no intrusive popups).
Please:
- disable your AdBlocker by adding CoolSoft website to whitelist
- give the proper cookie consent
- enable JavaScript for this website
This seconds wait is to let you update your browser configuration...
Ok, I've done the required changes... now show me your content!- David Berning
- Posts: 2
- Joined: January 23, 2022 - 20:59
- coolsoft
- Posts: 1997
- Joined: March 25, 2012 - 01:19
Thanks for reporting it.
That error indicates that the analog output device (the selected soundcard) configured as output for VMS device #1 can't be opened.
It could be that:
- the device disappeared (was it an USB device or a device bundled in an HDMI monitor?)
- the device is now in use by some other software that opened it in exclusive mode
Open VirtualMIDISynth.conf file with a text editor (in VMS folder) and look for a key like
[Advanced] ... OutputDevice=... ...
That key holds the configured output device for each VMS device.
Now close VMS and add a semicolon in front of that line to make it read like
[Advanced] ... ; OutputDevice=... ...
then restart VMS.
It should now use the default output device.
If this fixes the bug, please let me know the non-working value that was in that key...
- David Berning
- Posts: 2
- Joined: January 23, 2022 - 20:59
Thanks for the reply. Have been puzzling over this problem for a while.
Maybe this will help someone else:
I have a Focusrite audio device which uses an Focusrite ASIO driver. Some of the errors I was seeing talked about ASIO, so I did some looking and found there was a newer ASIO driver for the device. I installed it (with some trepidation ;) and the problem seems to have been corrected. Errors seemed to occur when the computer was put to sleep. There might also have been some threading errors in the driver. It seemed like the more open VMS devices, the more the errors happened.
BTW, I am a software developer. I like the VMS product - it must be fairly complicated. It would be awesome if it could output audio, but that might not be easy or possible.
I appreciate that there is support for it. 😁
- coolsoft
- Posts: 1997
- Joined: March 25, 2012 - 01:19
Thanks for reporting your findings 😉
- Ziya Mete Demircan
- Posts: 30
- Joined: April 19, 2017 - 08:14
Windows usually (r)enumerates devices when returning from hibernate/sleep state. // Depends on how deep the sleep state is 😂
Software that rescan the device's name and number and uses windows dll's are not affected.
// Adding "Use default output device" as an option may resolve this issue. (I'm guessing the default output device is always #1).
But some software such as Musescore and Audacity are known to have the similar problems.
Workarounds for those software are: Transport>"Rescan for audio devices" (for Audacity) and Edit->Preferences>I/O "Restart Audio and MIDI Drivers" (for Musecore).
Maybe consider putting a similar button in VMS?
What I wrote is my experience and thoughts on the subject, maybe it's meaningless 🤓
- coolsoft
- Posts: 1997
- Joined: March 25, 2012 - 01:19
Ziya Mete Demircan wrote:Windows usually (r)enumerates devices when returning from hibernate/sleep state
Yes, it does; and numbering became "garbled" in case of USB devices, which are searched on their bus and should always get the same ID... but sometimes the change it because of response delay and/or longer time to get out of sleep state.
Windows should send a notification to programs to inform them that the default device has changed, and this message should be received by BASS and switch it to the new default device almost transparently.
Actually VMS uses ID=1 to indicate the default device.
Ziya Mete Demircan wrote:Maybe consider putting a similar button in VMS?
I'd like to intercept that same message by myself and rescan the devices, as like as I do when pressing the Apply button after a configuration change.
The difficulty is in how to debug it because... it requires a sleep/resume cyclefor each test and, well, debugger is not so happy when resuming from sleep 😁.
Maybe I should get back to the old-style log to file debug mode 😉.
- Luis dlc
- Posts: 1
- Joined: November 20, 2024 - 13:31
coolsoft wrote:That key holds the configured output device for each VMS device.
Now close VMS and add a semicolon in front of that line to make it read like[Advanced] ... ; OutputDevice=... ...then restart VMS.
It should now use the default output device.
If this fixes the bug, please let me know the non-working value that was in that key...
Hello, first time posting here; so the first thing I want to express ever is: Thank you so much for VirtualMidiSoft.
I just started to have this issue. The last time I used VMS I was using version 2.13.2, and with that version I got the error yesterday. The first thing I did was update to 2.13.9 but I still got the error with this; effectively, the error happened when resuming from hibernation (Windows 10).
This is how it looked for me, before editing the file:
[Advanced]
LangID=1033
OutputDeviceName=<unknown>
And this, how it looks after restarting VMS (and checking it does work again):
[Advanced]
LangID=1033
OutputDeviceName=<unknown>
; OutputDeviceName=<unknown>
In my case, the output device in use when the system was hibernated (and on resuming) is indeed the HDMI port of the GPU card (GT 730).
I know this thread is almost 3 years old, but If a fix was implemented in the current version, it seems it doesn't work in my configuration. :(
Navigation
Login
Support me
Click here if you want to support CoolSoft using PayPal