Open hacst opened 9 years ago
I'm searching for ways to connect my Digital Audio Workstation software (Reaper) to Mumble in order to receive/send audio between the two, and ASIO is the only way I found... and ended up here.
I can receive sound from Mumble into Reaper, and I can see Reaper through Mumble's ASIO config panel, but nothing seems to happen there. I'm not sure yet if I did something wrong or if Mumble's ASIO integration is the problem.
On the other hand, as far as I know, WASAPI doesn't supports this form of routing, so... how would this be possible without ASIO support?
@Zylann Probably related to #1472
JACK is a proper replacement.
Here's a video showing how to set it up: https://www.youtube.com/watch?v=zzd7naKzRgw
Our Windows builds don't include support for JACK, but we will add it as soon as possible.
https://jackaudio.org/faq/jack_on_windows.html JACK doesn't seem bad, but its low latency path still actually relies on ASIO (through portaudio in turn)
Nothing wrong in relying on an external library I guess.. but I wouldn't be so automatically sure that all these middle men together couldn't be worse at the end of the day.
From https://jackaudio.org/faq/jack_on_windows.html:
It connects (OUTPUT) to those audio drivers using the PortAudio project (so Jack can connect using dsound, wmme, WDMKS, ASIO, WASAPI, and WaveRT) depending on what the soundcard’s drivers support.
Native Jack applications can make use of the full power of the JACK audio and MIDI connection system (for instance, they can open or close Jack connections from within the application, rather than having to set an ASIO driver to use use JackRouter), also, the use of natively provided Jack ports provides the ability to sync audio streams between applications.
The JackRouter ASIO driver is “only” there so that users are able to use ASIO applications in the Windows context of JACK, but this connection obviously has some limitations that native applications won’t have.
Also, PortAudio uses the new IAudioClient3
interface described in #3503:
https://app.assembla.com/spaces/portaudio/git/source/master/src/hostapi/wasapi/pa_win_wasapi.c
It's entirely possible that the latency ends up being lower compared to ASIO.
Putting aside IAudioClient3 is W10-only, that's completely nice, dandy and possible indeed.
But the (almost-dead) portaudio library only seems to support it with regard to the most basic UWP needs. I couldn't find anywhere the required IAudioClient3::InitializeSharedAudioStream
for example
https://github.com/WeAreROLI/JUCE/issues/560
You're right, the only way to know for sure that the latency will not degrade is by measuring it with the ASIO backend and then with the JACK one, as soon as we have a Windows build with it.
The ASIO backend was never completely finished or properly maintained. ASIO also became pretty redundant with the introduction of WASAPI which allowed low latency audio on pretty much every audio device with much less driver issues than we saw with ASIO.
From this point of view ASIO is a maintenance burden we should get rid of. Windows is served well enough by directsound for WindowsXP legacy support as well as WASAPI for everything else.