Hi,
I read on official fb2k site (https://www.foobar2000.org/components/view/foo_out_asio) that
"Please note that this component is meant for systems where ASIO is the only available output method. It is highly recommended to use the default output modes instead of ASIO. Contrary to popular "audiophile" claims, there are NO benefits from using ASIO as far as music playback quality is concerned, while bugs in ASIO drivers may severely degrade the performance."
It`s confuse me a little bit is it right? Or situation is more complex?
It's basically true. While Directsound is (IMO) a poor choice for hi-fi playback, because god knows what's going on in its inner workings, there's a much more convenient alternative - WASAPI. There are some cases though where ASIO may be viable. For instance in my case asus xonars are only capable of switching sample rate according to the source sample rate in ASIO mode, otherwise resampling occurs. While most people would argue that resampling itself would be inaudible (which may very well be true), I prefer less meddling with my audio stream. To put it short, if none of the above makes any sense to you, stick to WASAPI.
I want to see proof of your claims.
Refer to TOS8.
I want to see proof of your claims.
Refer to TOS8.
Whose claim? I don't think the OP is claiming anything, just asking a question.
I've always used ASIO with FB2K but it's got nothing to do with sound quality. Both it and WASAPI ought to pass a null test. In my case it's because my whole studio (PC, audio software, RME interface, external converters and outboard gear) is clocked to the main external Crookwood ADC, and that in turn uses the RME interface to communicate with the PC, with it's rock solid ASIO drivers. So it's just by default really, I use ASIO for everything else so stick with it for Foobar too. I have experimented with WASAPI modes and they work fine too. So I agree with the statement that "there are NO benefits from using ASIO as far as music playback quality is concerned".
asio is great - low latency, exclusive sound so no other pesky unwanted sound can bother you listening (a software alarm, auto play videos, spam, any sounds ona web brwoser etc,.)
i'd say the quality is better, as you never are forced to stop imerging in the music - ASIO FTW
and wasapi causes quite a strain in the hardware, so not a good choice.
i'd say the quality is better
You need to prove it, see the
@mudlord reference to the TOS #8 above, it was something you clicked "agree" to when you signed up for this forum. Either that or just stop making subjective statements about audio quality, which is what I have begrudgingly taught myself to do whilst posting here. :)
https://hydrogenaud.io/index.php/topic,3974.0.html
It's easy to check with a null test, take the original file, capture the original file after playing via FB2K, load both into a DAW or audio editor, make sure you have things lined up sample accurately, flip the phase on one, and you should be left with, well, nothing... If you are left with SOMETHING, then the process was not bit transparent. If it's bit transparent and you still think you hear a difference, then either something is broken, or you are a victim of some form of cognitive bias:
https://en.wikipedia.org/wiki/List_of_cognitive_biases
He stated in the very same sentence, why he worded it so... geez
They are totally wrong, ASIO automaticlly change sample rate for playing track, for example one time I listen CD-Audio with 44.1kHz, other some Hi-Res files with 96kHz etc and ASIO will always play correct sample rate which is bit-perfect playback.
WASAPI do not support this, so it's total useless.
I'm using ASIO for my Asus Xonar STX II since years, and it's recomended from Asus also.
WASAPI exclusive behaves exactly like that. If that's not the case on the Asus sound card it means its drivers aren't following specs.
You people who think you need bit-perfect playback should perhaps test what kind of effect resampling actually has in the audio quality. Unless you are delusional you should notice that there is absolutely no difference in the quality.
I use ASIO because it provides volume control on the panel for each application and misc Windows output separately. The system is easy to understand for me, as this is how it was done before Microsoft integrated sound into Windows. The reliability under CPU load at realtime priority is also better than Direct Sound on Windows 7 (it got worse in Seven). No need for a replacement standard, especially from Microsoft, and new plugins, which, at best, will work just as well. I do use resampling with the SoX plugin, however, as it causes problems when I start two programs and they both try to request a sampling rate.
If that's not the case on the Asus sound card it means its drivers aren't following specs
Can you please give link to this specs? (Not that i don't trust you, just need direct quotation)
Generic info about exclusive mode: https://docs.microsoft.com/en-us/windows/desktop/CoreAudio/exclusive-mode-streams (https://docs.microsoft.com/en-us/windows/desktop/CoreAudio/exclusive-mode-streams).
As explained previously, if an application opens a stream in exclusive mode, the application has exclusive use of the audio endpoint device
And remarks from function that initializes audio session: https://docs.microsoft.com/en-us/windows/desktop/api/Audioclient/nf-audioclient-iaudioclient-initialize (https://docs.microsoft.com/en-us/windows/desktop/api/Audioclient/nf-audioclient-iaudioclient-initialize)
The client can either connect directly to the audio hardware (exclusive mode) or indirectly through the audio engine (shared mode).
...
An attempt to create a shared-mode stream can succeed only if the audio device is already operating in shared mode or the device is currently unused. An attempt to create a shared-mode stream fails if the device is already operating in exclusive mode.
And definition of exclusive is "limiting or limited to possession, control, or use by a single individual or group".
They are totally wrong, ASIO automaticlly change sample rate for playing track, for example one time I listen CD-Audio with 44.1kHz, other some Hi-Res files with 96kHz etc and ASIO will always play correct sample rate which is bit-perfect playback.
WASAPI do not support this, so it's total useless.
Yes, WASAPI do support this. I use WASAPI with foobar2k and it behaves exactly as you say (verifiable by my AVR's 'information' panel): switches output sample rates to whatever the rate of the file is; mine range from CD rate to 88.2 to 96 to 192kHz. Playback is also verifiable as bit-perfect because any DTS or AC3 file I play (undecoded) is correctly decoded by my AVR.
WASAPI exclusive behaves exactly like that. If that's not the case on the Asus sound card it means its drivers aren't following specs.
You people who think you need bit-perfect playback should perhaps test what kind of effect resampling actually has in the audio quality. Unless you are delusional you should notice that there is absolutely no difference in the quality.
Thank you for information @Case, @krabapple, If I'm not wrong years ago I remeber WASAPI do not support bit-perfect.
Can someone with Asus Essence One amp can confirm that LED Bit-perfect light when use WASAPI mode ?
Same on Xonar STX II, How can I be sure that bit-perfect are working via WASAPI ?
Of course when listening music via Foobar via WASAPI I do not hear other system sounds, but I'm not sure does it output corectlly file samplerate.
Like someone say:
WASAPI is a bit perfect output plugin but some say certain cards will not automatically change the sampling rate.
Without the ASIO driver on the Xonar, your card will output whatever sampling rate it is set for. So if you play media that is 16/44.1 and you have the card set for 24/96, your card will upsample to 24/96 output.
So this is not 100% sure how it is on Xonar cards.
There's an old way of testing Xonar cards for changing sample rate (not at all sure if ALL xonar cards are subjected or if this method is 100% accurate). When you play a file of a certain sample rate and then play a file of a different samplerate, with ASIO you would hear a pop before playback is started, which indicates the sample rate shift. The pop is not happening with directsound, and for me neither does it happen with WASAPI on my D1.
Again, not stating that resampling is audible or anything.
thanks Pollux88 I will try.
In Xonar family sound cards all audio output via WASAPI(regardless of the mode used) or DS is passed through Asus driver panel, which includes its own resampler. However, if the rate of the audio stream matches the rate chosen in asus panel, you'll get bit-perfect playback. If your library contains files with different sample rates and resampling everything to a one fixed rate with smth like SoX is not an option because of the unbearable noise at ~ -170 dbFS, then using asio makes perfect sense. It's the only output mode in which asus panel and thus the built in resampler are completely bypassed.
Teddy_the_barber - exactly, so only option is still use ASIO.
Regarding direct sound and "god knows what's going on in its inner workings".
Well, not much and definitely nothing top secret. The only things that can alter your audio stream are: 1. Resampler (does nothing when the rate is matched and if not, is transparent anyway), 2. Limiter ( does nothing if the signal is below -0.13dbFS) - has a pretty fast release time and is of high quality. Can be audible for really "hot" stuff, but is easily bypassed by simply reducing volume in foobar. 3. Dither (irrelevant, as it is easily disabled by choosing 24 bit output in audio settings). That's it, god knows and now you know.)))
In Xonar family sound cards all audio output via WASAPI(regardless of the mode used) or DS is passed through Asus driver panel, which includes its own resampler.
The picture says something different. I am not a fan on Xonar cards but I doubted your claim.
Reference:
Windows 10 Professional (x64) Version 1803 (build 17134.523)
Motherboard - Asus H97M-E Rev X.0x
3.50 gigahertz Intel Core i5-4690
256 kilobyte primary memory cache
1024 kilobyte secondary memory cache
6144 kilobyte tertiary memory cache
64-bit ready
Multi-core (4 total)
Not hyper-threaded
Intel HD Graphics 4600
Sound-card - ASUS Xonar Essence STX
Drivers - http://maxedtech.com/asus-xonar-unified-drivers/
Amplifier - Stax SRM1/MK2
Headphones – Stax SR-X
Reference CD:
Label - Sheffield Labs
Album - The King James Version
According to the electronic component manufacturers, audio amplifier design was perfected over 40 years ago. The audio conversion range of the DAC and analogue chips used on the ASUS Xonar Essence STX are beyond the range of human hearing.
The above CD was ripped to 16 bit 44.1kHz flac. Listening to the flac files with foobar, driver switching between ASIO and WASAPI reveals no audible difference. Every other album I possess is an inferior quality to the above. I cannot perceive any differences.
Windows 10 is a generic operating system designed for commercial work not professional audiophile reproduction. If there are any audio differences look at the computer setup first.
https://en.wikipedia.org/wiki/Audio_Stream_Input/Output
The ASIO layer was designed for professional audio by Steinberg Media Technologies GmbH (trading as Steinberg). Setting up a professional audiophile reproduction system requires competent Windows 10 skills. Ideally a Windows 10 compilation with all the bloatware removed, and only audio applications installed.
[link removed]
Only after setting up a dedicated computer system can an intelligent, rational, un-biased audio discussion be productive and yield results.
@40th.com You're outputting through S/PDIF. Obviously, in this case the audio stream can't be altered because that would make some audio undecodable. I was talking about analogue output.
You're outputting through S/PDIF. Obviously, in this case the audio stream can't be altered because that would make some audio undecodable. I was talking about analogue output.
In Xonar family sound cards all audio output via WASAPI(regardless of the mode used)
Is what you claimed. Anyway, still doesn't matter. PCM over S/PDIF is not encoded. LPCM "obviously" works perfectly fine being resampled and sent over S/PDIF (too basic a principle to get into). I have put up a proof showing exactly the opposite of what you claim. Others here have also, either by the same proof as mine, or saying the driver was poorly done. You have put up nothing but your belief that it must be so because you, or someone on the internet, says it is. As demonstrated here, you are wrong.
@40th.com, are you trying to manipulate or to actually clarify things here? Everything I claimed is true (and easily verified), except the fact I was talking EXCLUSIVELY about ANOLOGUE output. S/P DIF out mode disables the built in resampler, great, you showed this on your screenshots, nobody argues with that. Now try anologue out (which is being discussed in this thread) and show me where I'm wrong.
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.
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).
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 (http://ftp.tekwind.co.jp/pub/asustw/Audio_Card/Xonar_D2-PM/Xonar_D2_RMAA605_TestGuide.pdf)
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.
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.
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.
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.
@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.
(https://www.overclockers.ua/peripheral/asus-xonar-phoebus/17-big-asus-xonar-phoebus.png)
This is what the latest version of the control panel looks like:
(https://i.imgur.com/e7jvU9c.png)
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.
@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?
Volume control works. It also works with ASIO.
Edit: forgot to say that it is synched.
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?
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.
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.
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.
@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.
...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)
hr = IpropertyStorePtr->GetValue(myPKEY_AudioEndpoint_Supports_EventDriven_Mode, &isEventOkayVar);
where myPKEY_AudioEndpoint_Supports_EventDriven_Mode is
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.
@40th.com, I see. And what result do you get trying to output via Exclusive Event mode in foobar? Silence, error..?
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 (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):
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.
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.
the driver misreports
That sounds like Asus)))
Note that event support is WHQL requirement. I don't think anyone releases drivers that aren't WHQL signed.
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
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
RemarksThis 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.
From Windows 7 audio certification guide (accessible from internet archive (https://web.archive.org/web/20110106034614/http://www.microsoft.com/whdc/device/audio/Win7Logo_Aud.mspx) or here (https://studylib.net/doc/9883205/windows-7-audio-logo-changes)) you can see that event driven mode indeed has been a requirement since Vista:
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.
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.
@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.
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?
I personally use ASIO with foobar because of the custom channel mappings. My audio interface has 4 outputs, and my setup involves my studio monitors on the main outs (1/2), and a sub on 3/4.
With the custom channel mappings, I can set outputs 1/2 to front L/R and then outputs 3/4 to LFE. I use this alongside the subwoofer DSP as a linear phase crossover with adjustable delay for matching phase.
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?
In short, it operates like exclusive mode, but with others able to join into the fray. A bit more detail I see you want. First, the limiter. I don't know. Maybe, maybe not (
I suggest the likely answer in the detail below). It's not a well-documented WASAPI feature. The follow up to that might be, what about "bit perfect?" Since others are able to join in (notification, msgbox beeps, and so on), obviously not that, at least not all the time. But I can cover that with a, "you can't hear the difference, or are you saying can you?"
Think of this another way. CPU cycle waste is avoided. Say you have set the soundcard properties at a 96 kHz sample rate, 24-bit sample size, 6 channels. The system (shared mode) wants you to feed it at a mix of (I don't even know -- don't care) say the same 96 kHz, but a 32-bit float, same 6 channels (again, I don't know/don't care). So let's say a program like, oh fb2k, uses the system mix as its guide so it converts 44.1kHz/16-bit/6-channel to 96kHz/float/6ch to feed to WAS(API). That's a lot of
avoidable CPU being used. WAS may indeed use this as a sum buffer format to combine all the shared streams, but in the end, when WAS is done, that signal has to again be converted to 24-bit channel-samples (from float) the soundcard is set (in its properties). For what reason? Who wanted this? No one is happy. It's a grand compromise with no winner(s). That's a lot of wasted CPU cycles, not to mention cache pollution.
Now, still in shared mode, let's say a program like, oh JUKEBOX 2112, uses this quasi-new-fangled super-shared mode. In this case, I set up the session to use the format of the track being played: 44.1kHz, 16-bit, 6-channel. The LPCM bits that come out of JB2112 are the same LPCM bits that make it to the the soundcard, ASSUMING no other session is also playing. And,
the limiter, I don't know.
Let's take the stance that the person who thought up this great idea in the first place also considered that the limiter only needs to be active when MORE THAN ONE SESSION is feeding sound. Yes, I would prefer that case. Better to know for sure, but no one is talking. You could probably find out by looking for distortion of a loopbacked, fullscale tone.
As for the first part, what does it do when sample rates change? You mean my program, JUKEBOX 2112 (heh)? Same as if it were in exclusive mode. It waits until everything in one format finishes, and the gets things done for the next format. No difference at all. If you go to this webpage, you can see a video of it in action:
https://www.microsoft.com/en-us/p/jukebox-2112/9mwlm64kmd3n?rtc=1
Jukebox 2112 is a native program for x64/arm64. As you can see, zero latency is typical - on-the-fly RG calc (if desired), waveform generation, etc, all take place before the next track needs to start. Even if the format is changing the process is similar; JB simply doesn't start feeding itself until the old format is drained. If you want to go one step further, yes you probably would hear a gap in continuous sound (say, a tone), but it would be incredibly short. And why would you expect it to matter if the source material format has changed so drastically?
And to directly answer your middle question... again, Jukebox? It does nothing different than if you don't check that Force format matching! box. Everything is transparent to the operation. Jukebox itself has NO SRC. Never has. It doesn't need one. You MIGHT be thinking, 'well of course it does, so to get the shared mode system mix (...float, etc.).' Nope. Anyway, take a look at the video. Watch where it changes tracks (albeit, a FLAC CD).
- I looked at your middle question again. Mixer? What mixer? Jukebox 2112 is dictating what format the soundcard is to use, just like it were in an exclusive mode. The soundcard's properties aren't considered. Goes without saying, but just in case, the format chosen has to be a format the soundcard can handle.
In case you're interested, only one program can set a new WAS format for this. Another program can still do the Force format match! but it has to exactly match the first program's format. If a different format, WAS returns a "device is already format locked" code or similar. The other program can simply go again, but this time not trying to force the format. And yes, this other program will ultimately use the format as set by the first program (the second program won't have any notice of this - but it doesn't need to know). System mix still returns the old ... float... suggested format during all this. As I see this working here. YMMV.
40th.com, thanks, for your extensive answer. I didn't know these things were possible while still remaining in shared mode.
And just out of curiosity, with all the extra processing off and a single stream with fixed parameters being active, could it be that the latency is low enough to handle even real time recording without a need to resort to ASIO or exclusive mode?
And just out of curiosity, with all the extra processing off and a single stream with fixed parameters being active, could it be that the latency is low enough to handle even real time recording without a need to resort to ASIO or exclusive mode?
Exclusive/event can go down to 10 ms buffer periods by requirement (going by 3+YO memory), and in theory, a driver can support shorter buffers (the win7_aud pdf posted previously I think mentioned that it can go down to 5 ms, perhaps even less). Thing is, that needs driver support. None of the drivers I've seen (normal OEM/ODM drivers) go below 10 ms so saying that it's possible, and what you can do, are separate realities. And just saying 10ms doesn't mean you get 10ms in the end. Very likely changes based on sample rate, bit size, maybe channels. So I recall.
Shared mode can be as low-latency as exclusive mode, or close, in that case. That's assuming shared mode is not going into a needless mix buffer/etc - wrote about that last time, and that you don't have a sub-10ms driver. Sometimes close isn't good enough, though.
If you go to exclusive AND event, I believe that is the the lowest-latency path you can get
for sure with WASAPI.
... but to answer your question, as a guess, assuming everything I wrote the last time is the way it really is, then yes, you could get latency close to, or as low as, exclusive. If a driver offers sub-10ms buffer periods it probably would do so only for exclusive mode, though. Good luck finding such a driver offering sub-10ms. Real-time recording? I don't see why you need sub-10ms response when recording one way (in). But assuming you have a reason, then... maybe monitor levels. Tape monitor loops. Where did they go?
- P.S. This is about playback (render), not recording (capture). Does it apply to capture also? I haven't thought about it at all before, but after spending about two seconds (okay, 1 second) on it, I'd say no, super-shared mode is not for capture.
Stick to ASIO if you want super-fast turn-around (in and out/out and in). That has nothing to do with playback. As it's often written, if you use ASIO for playback you are looking for trouble. You're looking for trouble anyway, but trouble may be the price to pay to get what you need.
Stick to Exclusive if you don't want alarm notifications disturbing play.
I want neither of those, and I suppose most also don't. I keep it in a shared mode all the time. I don't hear system sounds (beeps, boops, whatever) except for, according to my Sounds panel, 'error' sounds. Shared works fine for me, and the rare alarm is important.
Again, thanks 40th. You saved me hours of googling)))
I want neither of those, and I suppose most also don't.
Most people don't. It's just that in 2019 a lot of people are still fighting the "evil" windows audio mixer without even trying to understand that they're bypassing the functionality they've already payed for and that (most important) it's really useful and mostly high quality (win 10 resampler is really fast and good, surprisingly, so is the limiter.)
I want to see proof of your claims.
Refer to TOS8.
I've always used ASIO with FB2K but it's got nothing to do with sound quality. Both it and WASAPI ought to pass a null test. In my case it's because my whole studio (PC, audio software, RME interface, external converters and outboard gear) is clocked to the main external Crookwood ADC, and that in turn uses the RME interface to communicate with the PC, with it's rock solid ASIO drivers. So it's just by default really, I use ASIO for everything else so stick with it for Foobar too. I have experimented with WASAPI modes and they work fine too. So I agree with the statement that "there are NO benefits from using ASIO as far as music playback quality is concerned".
I want to agree and add to this. If you're most of the readers here and have a sound output that uses WDM or WASPI, then use that. However, the audio professionals view those protocols as problematic and are historically distrustful of them.
Our DAs typically come with ASIO drivers written specifically for our converters and offer stability and other features that can't be guaranteed by some competing Windows options. (Although some vendors who live in audiophile and professional markets may choose Windows drivers, e.g. Benchmark Media). Audio engineers can't have the OS fiddling with our data stream due to the possibility of corruption of our audio. (Even Prism Sound has included a VERIFILE application that cross-checks data - and they use ASIO for their driver. We're risk averse). These issues may have lessened in recent Windows drivers iterations, but generally, you won't see a professional studio using WDM when an ASIO driver is available from our converter manufacturer.
Finally, I'm willing to go along with the idea that, presently, there are no fidelity issues with WDM. But that's not my concern in my day job. It's custody of the data stream.
In short, if you have stable WDM/WASPI drivers for your setup, then use those. Don't let someone scare you into thinking it doesn't sound as good.
Hope this helps.