search

thestk / rtaudio

A set of C++ classes that provide a common API for realtime audio input/output across Linux (native ALSA, JACK, PulseAudio and OSS), Macintosh OS X (CoreAudio and JACK), and Windows (DirectSound, ASIO, and WASAPI) operating systems.
Other
1.49k stars 318 forks source link

JACK backend treats other clients as hardware not as apps #341

Closed mxmilkiib closed 2 years ago

mxmilkiib commented 2 years ago

So folk on the VCV Rack forum were asking about performance issues when using JACK, so I asked in #jack on Libera and was advised it's because Rack uses RtAudio/RtMidi and these have a strange JACK backend implementation that treats other JACK clients as hardware to connect to rather than using the expected so-called virtual method of managing connections between apps in an audio graph.

garyscavone commented 2 years ago

If there are ways to improve the JACK backend implementation in RtAudio, I would be happy to consider PRs. I recently went through the JACK code (in the newdeviceselection branch) and worked a bit on the device querying code. Without seeing an example of a better way of doing things, nothing jumped out at me as being strange.

mxmilkiib commented 2 years ago

Might you have A/B tried performance tests between the JACK and other backends before? This is the problem the user has reported. JACK shouldn't add latency.

Rack itself has threading, internal resampling and many buffers to accomodate being able to use many audio interfaces at once, so the problem noted might not be an RtAudio issue.

In general, AFAIU from developers in #jack, performance issues whilst using RtAudio can arise in the case ; a) the user has many JACK system ports, as RtAudio will make enough buffers to handle them all; b) resampling, if the app requests sample rate not being used by JACK and the app isn't geared to then use what JACK is using in that situation, 3) interleaved buffers, if the app requests that also.

dromer commented 2 years ago

The problem is that RtAudio treats all programs as "device" i/o which is just wrong.

Instead of trying to "connect" to such a "device" it should just create i/o ports and not do anything. Let the user connect things in any JACK graph application, like qjackctl, patchage, catia etc.

9/10 RtAudio just gets in the way because it doesn't know how to interact with the JACK graph.

nyanpasu64 commented 2 years ago

The problem I experienced (on pipewire-jack) is that RtAudio tries to auto-connect to Firefox instead of the speakers, and fails with error RtApiJack::probeDeviceOpen: requested number of channels (2) + offset (0) not found for specified device (0:Firefox).. It appears that newdevicescanning now connects properly to speakers instead.

garyscavone commented 2 years ago

The latest post here was fixed with the new device selection updates. I don't see a way to address the original comment, since it seems to expect RtAudio to behave in a way it was not intended for.

dromer commented 2 years ago

What do you mean "not intended for"? Isn't the intention to support Jack?

Current UX for Jack implementation is broken.

But maybe you should mark this issue with #wontfix then, so it's clear for everybody that we cannot expect RtAudio to have relevant Jack audio support.

garyscavone commented 2 years ago

RtAudio provides a common API across many different audio APIs. What I think you are interested in is something specific to Jack that would not be relevant or possible with the other APIs. That is what I meant by "not intended for".

dromer commented 2 years ago

Sure, I get that it's a "lowest common denominator" thing for what's considered "unified". Which ends up being a very poor UX for Jack usage.