I was just trying out vl.audio and for our simple project it looks great but it would be handy to be able to create a project that doesn’t’ rely on Asio4all.
If our clients change their machines they have to reinstall Asio4All each time, so we’d like to keep it simple for them and us.
I see that there is the beginnings of a Wasapi-based engine under the hood, though I doubt I have time to figure out how to implement it (needed this afternoon and I have other features to work on). Therefore I probably won’t use vl.audio this time around but its otherwise a classy contribution I look forward to diving into privately.
Hmm, I see, I had a look at the VLAudio repo and it seems to be using the vvvv.audio.dlls. Despite the lack of loopback it isn’t so important in my case of simply playing audio as and when.
I saw in VLAudio that the wasapi is sort of there but unimplemented. It references the vvvv.audio dlls so I took a look in the vvvv.audio repo of yours and the publicly facing one hasn’t been updated in over a year. I guess you may have another repo of it somewhere or a non public development branch, but in the mean time I can’t see how you’ve got it working in vvvv beta.
@bjoern I got swept up in another project I’m sorry to say. I think I ended up converting audio sounds to black video to play them back with Mediafoundation
this could potentially be confusing since there is only one instance of the AudioEngine globally. of you have two different nodes that work with the same instance, it doesn’t represent what actually happens. that is why my initial work just improved the enum for outputs by adding the additional WASAPI options. so you could switch between both driver models with just one click.
It’s only a poc / wip… Thought it was more confusing to have (output)pins that only show valid information for one of the backends. I guess there’d also be a lot of isassigned and ifs. The way it is now the patches a lot cleaner imho. And you only use one or the other anyway.
Unfortunately I just discovered a problem. When the AudioEngine is running using WASAPI, vvvv doesn’t properly exit, upon closing the editor with Alt+F4 the process lingers in the taskmanager. Also happens when closing the patch first (ctrl+w) and then quitting vvvv.
Attached the VS debugger but it doesn’t show anything.
When killing the process with the taskmanager sometimes (not always) errors pop up in the event viewer.
Any idea what could be causing this?:
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ComponentModel.InvalidAsynchronousStateException
at System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle)
at System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control, System.Delegate, System.Object[], Boolean)
at System.Windows.Forms.Control.Invoke(System.Delegate, System.Object[])
at System.Windows.Forms.WindowsFormsSynchronizationContext.Send(System.Threading.SendOrPostCallback, System.Object)
at VL.Lang.Platforms.RuntimeHost.FTimer_TickSend(System.Object, System.TimeSpan)
at VL.Core.MainloopTimer.TimerFunctionStart()
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart()
–
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ComponentModel.InvalidAsynchronousStateException
at VL.Core.MainloopTimer.TimerFunctionStart()
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart()
yes, it is a trade off. I think the output info was just for me to debug while working on the WASAPI implementation, this can be removed. having an extra node that displays the current wasapi setup as you did is the better solution.
should be easy to fix, i can have a look.
the call stack doesn’t provide any specific info, but it is most likely that shut down/dispose isn’t called properly on the WASAPI device.
yes, that fixes it, but isnt correct, because there could be multiple nodes and if one disposes the engine, no other audio node would work anymore. so the create/dispose of the engine has to be bound to the app, not the node.
there is also the FLstudio asio driver, it works fine for me. install the trial version of FL-studio and make sure to include the ASIO driver. then uninstall FL-studio. the ASIO driver is installed separately.
Just to let you know. The bug in FlexAsio has been fixed in the latest release. I’ve tried the VL.Audio help patches and all seem to run fine. Only had to set the default Sample Rate to 48000 and Desired Input Channels to 0 on my machine otherwise I’d get exceptions.