search

naudio / NAudio

Audio and MIDI library for .NET
MIT License
5.55k stars 1.1k forks source link

New MidiOut fails in UWP #435

Closed ElklandTech closed 5 years ago

ElklandTech commented 5 years ago

Hi Mark,

First of all thank you for your efforts on Naudio! My app uses Naudio to play sound and handle midi messages (midiIn). I recently added some very basic MidiOut capabilities to my app but I am hitting an issue when running the app as UWP for the Microsoft Store. Below is the relevant code excerpt (VB.NET):

Public Class LLMidi ... Private WithEvents myMidiIn As NAudio.Midi.MidiIn Private myMidiOut As NAudio.Midi.MidiOut ... Private Sub InitializeMidi(NewDeviceID As Integer) myMidiIn = New NAudio.Midi.MidiIn(NewDeviceID) myMidiIn.Start() iCurrDeviceID = NewDeviceID End Sub ... Private Sub InitializeMidiOut() ... Try myMidiOut = New NAudio.Midi.MidiOut(iCurrDeviceID) bMidiOutConnected = True Catch ex As Exception bMidiOutConnected = False End Try End Sub ... End Class

The code runs without error when running the app as non-UWP, but when running as UWP the following code line fails with the noted error: FAILED CODE LINE: myMidiOut = New NAudio.Midi.MidiOut(iCurrDeviceID) ERROR MESSAGE: UnspecifiedError calling MidiOutOpen ERROR STACKTRACE: at NAudio.Midi.MidiOut..ctor(Int32 deviceNo) ADDITIONAL LOCAL INFO: iCurrDeviceID=0 ADDITIONAL INFO: myMidiIn successfully connects using the same device ID (0)

Any ideas for a workaround or fix?

Thanks so much!

markheath commented 5 years ago

Sadly, UWP apps are restricted in what APIs they are allowed to call, so I suspect that's the issue you're running into. The good news is that there is actually a MIDI API for UWP apps - details here:https://docs.microsoft.com/en-us/windows/uwp/audio-video-camera/midi, but obviously there's a fair bit of code to rewrite

ElklandTech commented 5 years ago

My app is a Windows Forms (legacy) app brought to the Microsoft Store via the Microsoft "Desktop Bridge"... https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root

...and packaged for the MS Store using the Visual Studio packaging project described here... https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net

Apps brought to the store via the "Desktop Bridge" have access to "all system resources" (full permissions) by default with no way for the developer to change or restrict it; so an API restriction, at least in theory, should not be the cause of the error. And given that MidiIn is functioning correctly...it would be odd for Microsoft to provide UWP access to MidiIn but not MidiOut.

markheath commented 5 years ago

I see. I've not tried the desktop bridge myself yet. Are you sure no other application has that MIDI port open?

ElklandTech commented 5 years ago

I'm continuing to work on this this morning. I'm thinking the physical midi devices I have connected to my system may be contributing to the issue...I only have a physical Midi-In device connected (a Midi/USB footswitch) and I do not have an actual Midi-Out device connected. Under this scenario in non-UWP I am able to initialize naudio.midi.midiout without error and then use it to send a (bogus) midi message (more on that in a moment). The lack of a physical Midi-Out device could be the cause of the UWP failure to initialize midiOut...not sure why the initialize behavior would differ for UWP vs. non-UWP but it clearly does.

I am using midiOut.Send solely as a way to keep the midi driver from going to sleep while my app is running...which it does almost immediately after sound stops playing on an MS Surface PC (presumably to preserve battery) which in turn creates significant latency issues for midi messages/events that occur while driver is in sleep state (it takes a second or so for driver to wake up the process the message/event).

Given the issues I hit with UWP & midiOut.Send, I am now working on an approach using repeated calls to naudio.midi.midiIn.Start which also appears to keep the driver awake but unfortunately introduces a brief interruption in sound-output triggered by the footswitch button push. I believe I can workaround the sound interruption...Coding on that now.

ElklandTech commented 5 years ago

Unfortunately no success in avoiding the interruption of sound related to approach using naudio.midi.midiIn.Start. Was able to avoid it on regular PC but not on MS Surface PC. Will need to explore other alternatives.

ElklandTech commented 5 years ago

Hello Mark, After failing to come up with an acceptable solution/workaround using midi (in or out), I decided to try and approach the issue from a different angle. In testing I noticed that the MS Surface tablet kept the midi driver fully awake as long as any sound was playing on the device. So....I used your NAudio.Wave.SilenceProvider to play "silent sound" whenever I want to force the midi driver to stay awake. The new approach seems to work in testing so far. Many thanks for your time and efforts!