Skip to main content
Topic: NO benefits from using ASIO ? (Read 2988 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
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:

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.

Re: NO benefits from using ASIO ?

Reply #52, 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
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.

Re: NO benefits from using ASIO ?

Reply #54
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.)

SimplePortal 1.0.0 RC1 © 2008-2019