Forum

Vl.audio wasapi

Hi,

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.

here is some more info on that:

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.

Hmm, I should’ve looked a bit harder. The branch was at the bottom, tagged as stale: https://github.com/tebjan/VVVV.Audio/tree/wasapi-driver-support

Thanks

@Hadasi did you manage to get this to work and do you by any chance have a working version?

@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

VL.Audio.0.2.24-wasapi.7z (1.7 MB)

Extract to some directory and start vvvv with args
--package-repositories Drive:\SomeDirectory

The changes I made can be found here:

  • Only tested playback with 2021.3.3 and 2021.4.0-0176
  • Asio seems still to work (as before)
  • Added AudioEngine (Wasapi) (experimental)
  • There is an additional Info node listing the Wasapi drivers and input devices
  • Wasapi Explanation patch in Help
  • Dynamic enums do not work for now: Inputs for Driver and Input Device are strings
  • Sample Rate also doesn’t work and even when setting it as integer value the resulting sample rate seems always to be 48000
  • Couldn’t figure out a way to set the Buffer Size

Thanks @tonfilm

6 Likes

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()

Added a Dispose that seems to have “fixed” it.
image

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.

Should I make a pulll request and add you as collaborator?

But don’t they stop working anyways if I delete the AudioEngine node (and start working again when a new one is created)?

that would be great, thanks!

need to check how this is meant to be used by an app.

@tonfilm

btw, you can use FlexASIO in WASAPI shared mode… that might solve all problems. did anyone try this yet?

EDIT: scratch that, there is one bug that needs to be fixed first:

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.

1 Like

I tried to use it in a project but it always crashed after some hours.

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.

1 Like