WASAPI audio on Windows 10

[mark_k]

You could run something like LatencyMon to see if any device drivers are responsible for disabling interrupts for a long time. For me Intel wireless card drivers were a culprit, so using wired Ethernet instead would reduce the chance of pull overflow/crackling with small buffer size.

All the vsync modes require a significantly larger buffer size to be overflow-free here. I don't know whether there's any scope for improving that (series of small delays servicing audio in between each, instead of one longer delay???), but don't use vsync if you want the lowest possible buffer sizes to be glitch-free.

Windowed, WASAPI EX 48kHz on Windows 10 1511:
No vsync: can use buffer Min (128), no pull overflow messages.
Low-latency vsync: need sound buffer 3 (512) for no pull overflow messages.
Legacy vsync: need sound buffer 4 (704) for no pull overflow messages.
Variable sync: can have sound buffer Min with no pull overflow messages, but sound is very glitchy/crackly. Buffer 3 (512) seems mostly crackle-free. (My laptop doesn't support variable sync so that's probably why crackling but no pull overflow messages.)

[mark_k]

An update on the high latency problem I mentioned before with a VirtualBox VM. After updating to VirtualBox 5.1.10 latency is much lower and the hang problem with my Windows Server 2008 VM seems to have gone away. One entry in the 5.1.10 changelog is "Audio: fixed a few 5.1.x regressions by using the audio code from 5.0.x until the audio overhaul is complete"

[Dr.Venom]

Hi Toni,

Quick question, just to be sure. Is the WinUAE Wasapi implemention using floating point data?

In the decription of the audiostack improvements for Windows 10, as mentioned earlier in this thread ( Audio_Stack_Improvements_in_Windows_10 ) it is said that

"[...]Applications that use floating point data will have 16ms lower latency. b. Applications that use integer data will have 4.5ms lower latency". Which means using floating point data results in 11.5ms lower latency versus using integer data.

I can't remember this difference ever being discussed at the time of implemention, that's why I want to make sure..

Apparently float can be set using the WAVEFORMATEXTENSIBLE structure, using the subtype KSDATAFORMAT_SUBTYPE_IEEE_FLOAT as described here:

WAVEFORMATEXTENSIBLE structure

and here: WAVEFORMATEX structure

[Toni Wilen]

It sounds more like previously floating point had much larger latency and now it is much lower. Integer didn't get as much reduction because it was already lower.

[Dr.Venom]

Originally Posted by Toni Wilen

It sounds more like previously floating point had much larger latency and now it is much lower. Integer didn't get as much reduction because it was already lower.

Hmm, that could be...

Would it be possible to support both formats in WinUAE such that we can test for any possible latency differences? (Apparently float is sort of only supported in shared mode by drivers..)

[Dr.Venom]

Originally Posted by Toni Wilen

It sounds more like previously floating point had much larger latency and now it is much lower. Integer didn't get as much reduction because it was already lower.

Possibly there's a separate performance gain tied to using float.

Looking at the two quotes from this link: https://msdn.microsoft.com/en-us/library/windows/desktop/dd370811(v=vs.85).aspx

An application that uses WASAPI to manage shared-mode streams can rely on the audio engine to perform only limited format conversions. The audio engine can convert between a standard PCM sample size used by the application and the floating-point samples that the engine uses for its internal processing.

and the "CD Quality" example at the bottom:

but it will convert samples to floating-point numbers before processing them. The audio engine will convert the floating-point samples in the output mix to 16-bit integers before playing them through the device

Because in the quote it says that the (Windows Wasapi) engine uses floating point for its internal processing, it would seem that feeding it anything else will lead to an extra conversion step?

(But I'm no expert on this, so it's mostly guessing..)

[Toni Wilen]

Use of floats would only make sense if whole audio paths uses floats but I am not going to have 2 audio paths...

Simple doing extra conversion pass at the end sounds pointless. (Why would application conversion be any faster than OS conversion?)

[Dr.Venom]

Originally Posted by Toni Wilen

Use of floats would only make sense if whole audio paths uses floats but I am not going to have 2 audio paths...

Simple doing extra conversion pass at the end sounds pointless. (Why would application conversion be any faster than OS conversion?)

True. So it seems to boil down to the question which Wasapi mode is used by the larger part of the WinUAE userbase: Wasapi shared mode OR Wasapi exclusive mode?

If the larger part of the userbase uses shared mode instead of exclusive, then it would make sense the convert whole audio path to float (and add conversion step to int when mode is exclusive).

Here's my reasoning (a bit elaborate I know, but makes it easier to pinpoint incorrect reasoning or assumptions..)

From what I understand in shared mode the wasapi engine is the "middleman" and it always converts to float for its own processing. Since this wasapi engine uses float, it makes no sense to feed it integer as it will always lead to an extra (costly?) conversion step.

winuae integer -> float (by wasapi engine) -> device (int?)

Conclusion 1: using float leads to performance increase in shared mode because conversion step by wasapi engine is skipped

I guess wasapi exclusive works quite different because there's no "middleman" / wasapi engine: the application talks directly to the device so it must use a stream format that the audio hardware explicitly supports. I guess this will be either float or int, but from what I know most devices only accept integer. Conclusion 2: it makes sense to keep audio path integer when using exclusive mode.

I guess we're on the same page regarding the above.

Now to the most relevant, Conclusion 3: if Wasapi shared mode is used by significantly more users than exclusive mode, than logical thing to do is to have whole audio path in float, and add float to int conversion for exclusive mode.

That way you keep one audio path, but in general the larger part of the user base will enjoy increased performance

Personally I'm using Wasapi in shared mode also, so I guess my vote would go to using float in the audio path and having the benefit of the increased performance..

[Dr.Venom]

Originally Posted by Toni Wilen

No because it is exclusive. Everyone would hate it. It is worse than DirectSound from user point of view.

I guess this is the quote I had in the back of my mind with my previous post

[vagrant]

Toni I have 2 questions.. both of which are probably annoying

First is I've noticed that the 'min' buffer seems quite high with my card (sb x-fi titanium pcie). I know that using the updated HDAudio driver in conjunction with onboard audio will allow lower limit, but is there any way to force a lower limit with the x-fi card? I could get away with setting max_buffer as low as 256 before pull was implemented.
Here's my startup log with 'min' buffer + low latency vsync. Notice the illegal instruction - this does not appear with other buffer settings.. only 'min'.

WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=48000 BITS=32 CurrentPeriodInFrames=512
WASAPI: GetSharedModeEnginePeriod() DPIF=512 FPIF=512 MinPIF=512 MaxPIF=512
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: InitializeSharedAudioStream() Period=512. HRESULT=00000000
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=48000 BITS=32 CurrentPeriodInFrames=512
WASAPI: '{0.0.0.00000000}.{7c412605-1785-4e79-8e0a-645efd07f4f0}'
WASAPI: Shared Pull CH=2 FREQ=48000 BUF=563 (1126)
Illegal instruction: 4e7b at 00FC0564 -> 00FC0582

My other question:
Since using pull mode, I have run many hundreds of OCS demos in CE mode and the vast majority have perfect audio with min buffer setting. However there have been rare cases where certain demos require huge buffer or non vsync mode for audio to be glitch free.
Current case is ASS by Essence.. unless I set to maximum buffer or disable low latency vsync there are audio pops/glitch throughout the entire demo. I'm not getting any pull errors in the log, and CPU usage is always low (~50%).. any idea what could cause this?

[Toni Wilen]

Originally Posted by ED-209

First is I've noticed that the 'min' buffer seems quite high with my card (sb x-fi titanium pcie). I know that using the updated HDAudio driver in conjunction with onboard audio will allow lower limit, but is there any way to force a lower limit with the x-fi card? I could get away with setting max_buffer as low as 256 before pull was implemented.

It was size of temp buffer, not the real buffer size. Result was worse latency than current method. (You can't force hardware/driver to use buffer sizes it refuses to support)

Here's my startup log with 'min' buffer + low latency vsync. Notice the illegal instruction - this does not appear with other buffer settings.. only 'min'.

You should a bit more testing and notice that it happens even if sound is disabled...

It is KS CPU type check and perfectly normal.

My other question:
Since using pull mode, I have run many hundreds of OCS demos in CE mode and the vast majority have perfect audio with min buffer setting. However there have been rare cases where certain demos require huge buffer or non vsync mode for audio to be glitch free.
Current case is ASS by Essence.. unless I set to maximum buffer or disable low latency vsync there are audio pops/glitch throughout the entire demo. I'm not getting any pull errors in the log, and CPU usage is always low (~50%).. any idea what could cause this?

CPU usage may not work reliably in pull mode. Easy check: try direct sound, if glitches: it is due to CPU usage (even easier to confirm by switching CE off on the fly).

[vagrant]

I should have test the illegal instruction some more sorry

Running ASS, with wasapi shared & min buffer; switching CE off causes the demo to run VERY slowly during effects.. maxing the buffer at 10 makes no difference.

Running with DSOUND the audio is 100% stable at buffer 2. If I then switch back to wasapi/pull mode, the pops/glitches start to creep in again.

Also, with CE off, the demo suffers huge slowdown during effects regardless of which sound device is in use (even if sound is disabled).

[vagrant]

came across another odd case.. AGA musicdisk Crossroads by Jewels.
This one I can't get clean sound with pull mode no matter what buffer settings I use.
It clicks/pops with buffer settings from min to 6.. going any higher messes up playback timing.
Tried with 020 CE on/off, JIT enable/disable etc.
It uses mixed modes so not sure if this have anything to do with it.

[Toni Wilen]

Could you find out which beta introduced this? It may not be exactly sound related. (=did it start in 3.4b1?)

EDIT: HD installable programs don't count. Too many variables!

[vagrant]

Seems I can no longer reproduce the problem with Crossroads anyway.. the audio is working fine now and absolutely nothing has changed.. strange

I spent some time going back through releases with ASS by Essence.. there is audio issues in 3.3 public, before pull mode was even implemented, so looks like some silly demo-specific problem, sorry. I know it has run without issue in the past as I've got a 100% capture of it on my youtube channel - though it's dated november 2014, so that's a lot updates since then.
Anyway, I'll be sure to find specific beta before reporting any more issue

[mark_k]

I came across this article: Finally Windows 10 could support audio!
And a couple of threads on social.msdn.microsoft.com:
WIN10 Major Issue for Audio Processing (OS special mode for small buffer)
Pro Audio In Vista/Windows

A reply from someone at MS in the first thread says:

Thanks for sending me traces and discussing with me offline. After looking at the traces, we see that your realtime thread is running into page faults when doing memcpy.
I will refer you to Larry Osterman's advice in this other thread:

You are running a Fall Creators Update (RS3) build; after chatting with the memory manager devs, there have been some changes in RS4 to make this particular kind of page fault less common.

So... could using VirtualLock() to lock audio buffers (and maybe all WinUAE code/memory?) help to reduce audio glitches with small buffer sizes? Maybe even glitches when in vsync modes, which for me need a larger buffer setting to avoid or reduce?

[Toni Wilen]

I don't think it helps except by going against recommendations and locking all the memory which can cause all kinds of bad side-effects on lower memory systems..

It is also different problem, afaik problem mentioned in links is caused by paging in previously unused (or unused for long enough) source buffers, which don't exist in emulation that generates all sound samples on the fly to sound driver's output buffer. (which you can't virtuallock)