Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: NO benefits from using ASIO ? (Read 11411 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: NO benefits from using ASIO ?

Reply #25
 
Everything I claimed is true (and easily verified)

So do it.  And then show how you did it so anyone else here can repeat it and see this for themselves.  Do it using at least two or more unrelated, readily available software chains, and over all generally-used sample rates.  You are the one making the claim.  You are the one needing to prove it.

And I know it was mentioned here, but here you are already in the analog realm, well-beyond any sort of bit-perfect nonsense, where the distortion from the DAC and output section is far more than any resampler.  Just to show the stupidity (had to say it) of your claim.   If you can prove, so that any one here can also verify your results, that

In Xonar family sound cards all audio output via WASAPI(regardless of the mode used) [resample]

then I, and anyone here I would expect with a "Xonar family sound card", want to see you prove it.  While you are at it, prove that all "Xonar family sound cards" using asio don't resample.  Don't come back until you do or you'll be wasting everyone's time.  Don't.  Just don't.
BANNED

Re: NO benefits from using ASIO ?

Reply #26

where the distortion from the DAC and output section is far more than any resampler.  Just to show the stupidity (had to say it) of your claim.
 
Where exactly did I say that resampler is something bad? A few posts back I mentioned that there's no need to output at different rates (and stick to ASIO for that reason), because using SoX resampling produces absolutely inaudible artifacts (Win 10 resampler artifacts are at ~ -108 dbFS at default setting - so inaudible).
Quote
So do it.  And then show how you did it so anyone else here can repeat it and see this for themselves.
Choose WASAPI or DS in foobar, play a track, then go to Asus panel and switch between sample rates, you'll hear a click everytime you change it, all surround effects and volume control work as well. Now select ASIO output in foobar and do the same - nothing happens. It will not respond neither to volume control, nor to any effects, nor to sampling rate changes. Also, when you record a rightmark test signal through ASIO from foobar, results will be correct regardless of the sample rate set in Asus panel, but if you choose any other output and sample rates don't match, you get poorer results, that's how you know SRC is involved.
Also, in their Xonar D2 RMAA Test guide they specifically remind a couple of times that source sample rate and the one set in Asus panel should always be matched. Read it: Here

Re: NO benefits from using ASIO ?

Reply #27
You are correct.  There's a much simpler way to see it.  Still using the toslink, select "Speakers" as the output device instead of "S/PDIF Pass-through Device".  The speaker endpoint routes through the toslink.  The AVR shows the rate set in the Xonar DX Audio Center regardless. This is a DX from 2008.  Carry on. 

Still using exclusive mode (same result for shared).  FTR, my DX does not do exclusive-event or shared-event, just timer modes.
BANNED

Re: NO benefits from using ASIO ?

Reply #28
Quote
There's a much simpler way to see it.
Of course, if you have a way to instantly see sample rate changes on your AVR display, it's even better.

Quote
my DX does not do exclusive-event or shared-event, just timer modes.
Interesting. What OS are you using? Have a d1 and an Essence ST, both work perfectly in all output modes ( Win 10 64bit). Again, I'm not using S/PDIF passthrough device. Maybe it has smth to do specifically with that mode. Speakers - # of channels - Analogue out, then set to WASAPI event. Should work.

Re: NO benefits from using ASIO ?

Reply #29
I have at least one exception to the claim that all Xonars do that. I have Asus Xonar Phoebus and its drivers do not mutilate WASAPI or anything else. I just ran RMAA test using foobar's exclusive WASAPI output while Asus control panel was set to 44.1 kHz and 16-bits and frequency response showed pretty much flat line up-to 50 kHz and SNR was 112 dB.

Re: NO benefits from using ASIO ?

Reply #30
@Case, I see that Phoebus stands separately in their lineup with its own control panel and behavior. Could you try and repeat the actions I described in post 26 and tell us what you get.
Also, screenshots of your Asus Rog Speakers Setup window and Win audio setup would be nice.


Re: NO benefits from using ASIO ?

Reply #31
This is what the latest version of the control panel looks like:


Changing playback configuration here affects the default format of the output device which you can set in the device's properties dialog. Touching it while playback is active makes foobar2000's exclusive WASAPI playback stop, and it works the exact same way with for example standard High Definition Audio Device running built-in Windows drivers.

None of the effects do anything when using exclusive WASAPI. They do work with shared WASAPI though.

Re: NO benefits from using ASIO ?

Reply #32
@Case, I understand. Seems like ROG driver is different from everything else made by Asus. The bit depth and rate are synchronized, which doesn't happen with the rest of their drivers.  Even the newest Essence STX II still behaves the old way. What about the master volume control in exclusive mode, does it work? Is it sync'ed with the one in Asus panel?

Re: NO benefits from using ASIO ?

Reply #33
Volume control works. It also works with ASIO.
Edit: forgot to say that it is synched.

 

Re: NO benefits from using ASIO ?

Reply #34
Volume control works. It also works with ASIO.
Edit: forgot to say that it is synched.
Let me get this straight, Win master volume and the one in Asus panel are sync'ed and work even with Asio?

Re: NO benefits from using ASIO ?

Reply #35
Well, that just goes to show that with ROG it is different. Thanks for your input, Case.
PS I think the way your drivers work is a lot more preferable, than we see in the rest of Asus models. It looks like the old drivers' behavior was created for WinXP. Now that Windows since Vista has a lot more sophisticated mixer and additional exclusive output modes, the extra resampler baked into the driver doesn't make any sense.

Re: NO benefits from using ASIO ?

Reply #36
Let me get this straight, Win master volume and the one in Asus panel are sync'ed and work even with Asio?
That's correct. I recall on Creative cards I have had ASIO even allows full mixing of other sounds.

Re: NO benefits from using ASIO ?

Reply #37
Please do not link to illegal modified Windows ISO images on this forum. Also, please do not use such "trimmed" OS installations, you're entirely on your own if anything breaks. Don't expect this forum to help you if something that works on a vanilla installation of Windows happens to break on your special installation.

Re: NO benefits from using ASIO ?

Reply #38
@kode54, If your message was addressed to me and you meant the link I gave in post 26, it's a direct link to a .pdf file. I have no idea what is on that site apart from that document, it was the first thing google came up with. If you found something that violates any of the rules here, then delete it.

Re: NO benefits from using ASIO ?

Reply #39
...about event mode, wasapi

This is indicated by the driver, from an API call.  It has nothing to do with the endpoint (so Speaker, SPDIF, maxnix).  It's the Asus driver.  The picture shows a typical result (typical if such a thing is reported; it's the only one I know of that does this).  The API is (my call to it)

Code: [Select]
hr = IpropertyStorePtr->GetValue(myPKEY_AudioEndpoint_Supports_EventDriven_Mode, &isEventOkayVar);

where myPKEY_AudioEndpoint_Supports_EventDriven_Mode is

Code: [Select]
DEFINE_GUID(myGUID_AudioEndpoint_Supports_EventDriven_Mode, 0x1da5d803, 0xd492, 0x4edd, 0x8c, 0x23, 0xe0, 0xc0, 0xff, 0xee, 0x7f, 0x0e);

Means nothing to most, but in case you wanted to know why this is, or could use it yourself.  It's pretty much a given anyone doing waspi will already know this call.
BANNED

Re: NO benefits from using ASIO ?

Reply #40
@40th.com, I see. And what result do you get trying to output via Exclusive Event mode in foobar? Silence, error..?

Re: NO benefits from using ASIO ?

Reply #41
It does play normally.  It is in exclusive, and I selected event.  I can't verify it used that event mode, though.  So, either

1. fb2k does not check if event mode is supported according to the driver (the driver mis-reports), or
2. fb2k silently moves up to timer mode on a failure  (moves up because in my testing, performance is better in timer mode, c.2015)

https://docs.microsoft.com/en-us/windows/desktop/CoreAudio/pkey-audioendpoint-supports-eventdriven-mode

I could check myself to see if event mode works here.  So, looking at the return, for the Xonar this returns an empty variant.  In my code, I consider that the same as not supporting it.  I looked in the .inf (search for *xonar*.inf in /windows/system32/DriverStore/FileRepoisitory/) and found no entry.

Here is a sample entry in hdaudio.inf that has it (no such entry in xonardx.inf, hence the empty variant returned from the API call to check if it's supported):

Code: [Select]
HKR,DeviceInterfaces\%KSNAME_eSpeaker%\DeviceParameters\MSEP\0,%PKEY_AudioEndpoint_Supports_EventDriven_Mode%,0x00010001,0x1

To wrap this up: I don't see why one would offer event mode when it doesn't indicate that it will work, especially since timer mode is the better mode, or at least no worse.  If you want to know why it could be "better", events have to come from the driver, so this means a kernel-to-user context switch (ring0 to ring3).  Timers are in the same context as the programs that use them, so no context switch.  All "pretty-sure", there.  As to how much impact that has, probably a bit more than the timing's margin-of-error, but in real life, not much.
BANNED

Re: NO benefits from using ASIO ?

Reply #42
fb2k silently moves up to timer mode on a failure
That's weird. That would have to be the common behavior, because I just tried event mode with aimp and winamp and they're working fine.
Quote
the driver misreports
That sounds like Asus)))

Re: NO benefits from using ASIO ?

Reply #43
Note that event support is WHQL requirement. I don't think anyone releases drivers that aren't WHQL signed.

Re: NO benefits from using ASIO ?

Reply #44
That's weird...
I wrote those two options before I checked it out in my code (lengthy process since another machine).  What fb2k does is not check if event mode is supported.  In other words, damn the torpedos, full speed ahead is fb2k's way.  Probably like playing golf while thunder is about.  Not gonna happen to me... haha
BANNED

Re: NO benefits from using ASIO ?

Reply #45
Note that event support is WHQL requirement. I don't think anyone releases drivers that aren't WHQL signed.

Is it?  I know that it is a WHQL requirement to report if the driver supports it or does not.  It's in the link I posted

https://docs.microsoft.com/en-us/windows/desktop/CoreAudio/pkey-audioendpoint-supports-eventdriven-mode

Remarks

This property value is populated by an audio OEM in an .inf file to indicate that the HDAudio hardware supports event driven mode as per the WHQL requirement.

Maybe you read into that that events are required.  My read is that it requires the driver to indicate if it supports events  -- or not.  The xonar dx driver does not indicate either - it's empty.

I can see some hardware not doing events.  For example, if you go way back to the Multisound (the original), or very first Soundblaster (waveform did not work in Win31).  Those did programmed I/O instead of using a buffer filled by DMA.  Using DMA you get hardware events as often as you like when the dma location reaches what positions you are interested in (typically at the middle and end).  Using programmed I/O you don't.  But programmed I/O in this day (well, since Windows 3.1) is too unlikely, but maybe the driver people didn't want to bother.  One could probably assume that events are going to happen and not do the API call to check.  Me, I'd rather check.
BANNED

Re: NO benefits from using ASIO ?

Reply #46
From Windows 7 audio certification guide (accessible from internet archive or here) you can see that event driven mode indeed has been a requirement since Vista:
Quote
In Windows 7, we changed the user-mode audio engine to run in event-driven mode (also known as pull mode) by default to improve round-trip latency. [...] The requirement for audio drivers to support event-driven mode existed in Windows Vista®. In Windows 7, we improved logo test coverage for this requirement and added some design notes that had details on the INF file setting to configure the audio subsystem for the driver.

Re: NO benefits from using ASIO ?

Reply #47
From...

Not sure why that's so well hidden now.  Here is a PDF of it, and the docx.  The relative section is on page 13 of 21.  It claims for best round-trip latency to use event mode.  Not what I measured when I decided to default to timer mode, which I believe was total time spent in the API calls feeding the buffers (JB is not disk-bound; it loads and decodes the entire file into memory - easy to set things up so there's no disk at all for a test).

For players, this type of latency is not a prime concern, compared to say, recording, where it could be, or what most complain about when it comes to Windows audio: pressing a virtual key on a virtual keyboard, or a real controller, and hearing the sound instantly, not 50 or 100ms later.  And with that, back on topic.  That is where ASIO was useful.  And why Steinberg came up with it.  Latency.  Why anyone would go out of their way to use it for a player makes me wonder.  No, not really.

BTW, on the Xonar machine are three soundcards (it and an xfi and idt-on-mobo).  None are WHQL'ed according to dxdiag.  Xonar's driver is Jun. 2015.  Xfi (PCI) was pre-Vista, but a Dec. 2015 driver.  IDT is Oct. 2011.

P.S. Anyone here know that it is possible to specify the sample rate, channels, and sample bitsize for WASAPI shared mode?  It is.  You can, just like exclusive mode, have the hardware run at 44100, 6 channels, 16-bit samples, from shared mode.  No SRC, and no conversion to float.  I'm doing it right now.  Check out

https://hydrogenaud.io/index.php/topic,117073.msg967437.html#msg967437

the Force format matching! checkbox.  Just a FYI.  No real downside compared to exclusive mode, unless your goal for EX mode is to prevent notification ducking/sounds when playing.
BANNED

Re: NO benefits from using ASIO ?

Reply #48
@kode54, If your message was addressed to me and you meant the link I gave in post 26, it's a direct link to a .pdf file. I have no idea what is on that site apart from that document, it was the first thing google came up with. If you found something that violates any of the rules here, then delete it.
No, it was directed at a user who registered just to post in this topic, and who is now banned.

Re: NO benefits from using ASIO ?

Reply #49
the Force format matching! checkbox.  Just a FYI.  No real downside compared to exclusive mode.
No SRC, and no conversion to float.
And how does it handle files with different sample rates? Does it prescan the next file and then sets the parameters to match the mixer setting? What about the limiter?