04 December 2016, 21:19 | #61 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,336
|
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.) |
06 December 2016, 21:40 | #62 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,336
|
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"
Last edited by mark_k; 06 December 2016 at 21:53. |
23 April 2017, 19:46 | #63 |
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
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 Last edited by Dr.Venom; 23 April 2017 at 19:50. Reason: corrected link |
23 April 2017, 19:49 | #64 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,506
|
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.
|
23 April 2017, 19:54 | #65 | |
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
Quote:
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..) Last edited by Dr.Venom; 24 April 2017 at 09:12. |
|
24 April 2017, 09:11 | #66 | |||
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
Quote:
Looking at the two quotes from this link: https://msdn.microsoft.com/en-us/library/windows/desktop/dd370811(v=vs.85).aspx and the "CD Quality" example at the bottom: 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..) |
|||
24 April 2017, 17:56 | #67 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,506
|
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?) |
01 May 2017, 11:14 | #68 | |
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
Quote:
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.. |
|
02 May 2017, 09:43 | #69 |
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
|
20 May 2017, 08:46 | #70 |
Registered User
Join Date: Mar 2012
Location: Australia
Age: 44
Posts: 1,126
|
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'. Code:
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 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? |
20 May 2017, 10:49 | #71 | |||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,506
|
Quote:
Quote:
It is KS CPU type check and perfectly normal. Quote:
|
|||
20 May 2017, 15:52 | #72 |
Registered User
Join Date: Mar 2012
Location: Australia
Age: 44
Posts: 1,126
|
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). |
02 June 2017, 08:04 | #73 |
Registered User
Join Date: Mar 2012
Location: Australia
Age: 44
Posts: 1,126
|
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. |
02 June 2017, 17:30 | #74 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,506
|
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! Last edited by Toni Wilen; 02 June 2017 at 19:28. |
03 June 2017, 11:17 | #75 |
Registered User
Join Date: Mar 2012
Location: Australia
Age: 44
Posts: 1,126
|
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 |
18 February 2018, 14:20 | #76 | ||
Registered User
Join Date: Aug 2004
Location:
Posts: 3,336
|
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: Quote:
|
||
19 February 2018, 09:46 | #77 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,506
|
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) |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Noise when dragging emulation window with WASAPI EX sound | mark_k | support.WinUAE | 0 | 22 August 2016 20:59 |
Best Audio Config in Winuae for a Creative X-Fi Audio Card | shaf | support.WinUAE | 2 | 14 June 2012 16:27 |
winuae 1.6.1 in Windows 7 and WASAPI audio | Gaula92 | support.WinUAE | 12 | 13 July 2009 09:14 |
Crash using Portaudio WASAPI mode | Ian | support.WinUAE | 6 | 31 May 2009 03:34 |
cd audio | SexyWayne | support.Hardware | 4 | 04 May 2005 01:47 |
|
|