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 11686 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: NO benefits from using ASIO ?

Reply #50 –
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.

Re: NO benefits from using ASIO ?

Reply #51 –
Quote from: Teddy_the_barber on
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.
BANNED

Re: NO benefits from using ASIO ?

Reply #52 –
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?

Re: NO benefits from using ASIO ?

Reply #53 –
Quote from: Teddy_the_barber on
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.
BANNED

Re: NO benefits from using ASIO ?

Reply #54 –
Again, thanks 40th. You saved me hours of googling)))
Quote
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.)

Re: NO benefits from using ASIO ?

Reply #55 –
Quote from: darkflame23 on
Quote from: mudlord on
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.