This project has moved and is read-only. For the latest updates, please go here.

NAudio in a non GUI thread

May 31, 2012 at 7:03 AM

My program uses Naudio.Wave.WaveOut to play out audio on a USB audio device. If the USB audio device is removed during playback to GUI playback panel is no longer updated. Any interaction with the playback panel result in the whole program to freeze. My approach was to move all the Naudio.Wave.WaveOut functionality into its own thread (BackgroundWorker to be presice) so that if playback bombs out it will not influence the GUI thread in a negative manner. However, try as I may (wasting almost 2 days) I just could not get audio to play out using  Naudio.Wave.WaveOut from a non GUI thread. I also tried WaveOutEvent without luck. All I got was one callback with stopped state after issuing play.


Is there something fundamental about WaveOut and WaveOutEvent that it will only work in a GUI thread? Also I want to add that WaveOut is way more robust than WaveOutEvent if you really hammer a play/pause button.

May 31, 2012 at 11:35 AM

WaveOutEvent is what you should be using if you don't want audio on the GUI thread. I fairly recently added some code in to handle removing USB audio devices so make sure you are working with the very latest NAudio (I have some preview builds on nuget)



May 31, 2012 at 12:18 PM

Yes, I did use the very latest code, naudio_60216c3b9380,  and in a  non GUI thread WaveOutEvent was not working for me.

May 31, 2012 at 1:26 PM

what about if you run NAudio demo? does playback work as normal in that with WaveOutEvent selected?

Jun 1, 2012 at 5:04 AM

In NAudio Demo (x64), using AudioPlaybackPanel with the Ouptut driver set to 'WaveOut' and the callback Mechanism set to 'Event' playback does work. WaveOutEvent is used but it is defined within the scope of AudioPlaybackPanel. My initial thought was that Playback was happening on the GUI thread. On closer examination I realised that playback is indeed happening in it own thread. Removing the USB audio device during playback did result in a stop event in which e.Message was not null. So all is well with the demo.


Removing the USB audio device during playback does not in all cases result in a stop event. My program is capable of recording and playback independently and both can happen at the same time. When the USB audio device is removed the playback stop event never fires (probably because WaveIn bombs first and no further clean-up is scheduled).


I guess if either the recording or playback bombs that both are no longer functional. 

Jun 2, 2012 at 10:29 AM

I would expect both WaveIn and WaveOut to report errors on the USB device being removed. I can't understand why you wouldn't get a playback stopped event.

Aug 28, 2012 at 8:45 PM

WaveOut in FunctionCallback mode does not generate a PlaybackStopped event on USB device pull out. I switched to WaveOutEvent and that worked.

Sep 5, 2012 at 5:38 PM

I don't recommend using FunctionCallback. It has been nothing but trouble. WaveOutEvent is the preferred approach.