WASAPI Exclusive mode


#1

Hello all,

I’m have my application working nicely with WASAPI shared mode and thought I’d have a bash with exclusive mode. I saw this post:

http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=11076#p62809

And so tried simply setting the useExclusiveMode bool to true. My application loads but the audio output (supposed to be sine) sounds pretty gnarly. It’s fine inside the appliation - I route it internally to a waveform/spectrum display and it looks OK, but it sounds awful. Before I spend time trying to work out what the problem is, perhaps someone could do me a huge favour and answer this:

Am I being totally naive expecting to be able to just change this one parameter and have exclusive mode work? Are there more fundamental changes to my application that need to be made? Am I missing something pretty obvious?

Thanks muchly,
Pete.


#2

No, it’s not a mad idea! But that flag was only ever an unfinished experiment, not something that was ready for public use.

Probably the only thing that’d need finishing would be the fact that in exclusive mode I don’t think it’s possible to choose the samplerate or buffer size, so most likely the other wasapi code is assuming those things have been successfully changed and are using the wrong ones.


#3

OK thanks Jules. That seems to make sense.

I’ve fed the soundcard output back on itself and I can now visualise the distortion: there are discontinuities in the sine wave. Interestingly, when the sine frequency is an integer divisor of the sample rate it outputs fine.

Fiddling around I can see that 100Hz is OK, but the picture below shows that 50Hz is truncated to half a cycle. My application is being told by the sample buffer (in an audio processor) that the sampling rate is 48k and block size of 480 samples - the same as shared mode. The half-cycle truncated sine seems to imply that the system is just taking the first half of each buffer - so maybe the actual block size is 240 samples.

Sadly, delving into the WASAPI code is way, way beyond my current understanding, so I’ll have to wait until this is implemented. Unless someone else has had a meddle and come up with something satisfactory?

Is WASAPI exclusive mode planned now that Tracktion is alive again? (great news btw :slight_smile:


#4

 

 

Jules -

 

What's going on with this?  Will we be able to use WASAPI in exclusive mode anytime soon?  

It seem that the vast majority of new windows machines have WASAPI as the only driver out of the box, and have inputs/outputs that don't share a common sample rate (so says the AudioDeviceMananager).  

 

In other words - ton of users try out JUCE apps and get nothing because they expect it to work on their crappy WASAPI windows devices.

 

 

By the way - it does work fine with just the output enabled - so I guess that might be the best workaround for now, huh?  I should have thorught of that sooner : )

 

 

 


#5

This had dropped off my radar, I'm afraid. TBH the most awkward thing would be finding some way to make it an option that's visible to the user, because often you may want them to be able to choose between exclusive/non-exclusive mode. Perhaps it would make sense there to be two different device types, i.e. normal shared WASAPI and WASAPI-exclusive?


#6

 

Well, speaking for myself, I would be quite comfortable forcing users to use exclusive mode and thereby gain inputs.

Perhaps it could be something that we programmers could set, whether or not you ever expose it to the users.

 

Of course, Windows can be set up to disallow exclusive mode, so I suppose we woul dhave to handle that.

 

Whichever path you chose, it would be great if it were just working.  I see the same issues noted above.  Tried tinkering with buffer size but didn't get it to work.  Give it a look when you have a minute.

 

Thanks as always!


#7

+1 for WASAPI Exclusive

  • Allows users with non pro audio hardware to get lowest latency possible
  • Doesn't require users download additional drivers (like Asio4All) to get lowest latency possible
  • Lets users change the sample rate of their I/O without having to go to the Windows control panel
  • Gives more than one sample rate option
  • Allows software to avoid dreaded input/output sample rate mismatch error which can currently only be resolved by going into the Windows Control Panel

Perhaps it would make sense there to be two different device types, i.e. normal shared WASAPI and WASAPI-exclusive?

Considering the alternative is adding a Windows Audio specific checkbox to turn exclusive mode on/off, your idea is probably the best solution to fit it into Juce.


#8

+1 !!