Hi,
module-virtual-source is only an example of how a filter source should
be implemented and
is very rarely used. Module-remap-source is intended to be used if you
want to change the
channel map of your source. Module-remap-source has much less overhead,
so it is probably
the better option for your use case.
On the other hand, module-virtual-source provides the uplink_sink
option, which creates a
sink that is mixed into the virtual source, which means you would not
need the null sink.
If you are able to compile your own pulseaudio, you might want to try
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/661
This MR generalizes the uplink_sink feature so that you can also use it
with module-remap-sink
which should provide the lowest possible latency.
Regards
Georg
On 17.04.22 06:48, Chase Lambert wrote:
Hi,
I'm trying to make a low latency Virtual microphone. What that means
is I make a null sink, and then a module-virtual-source
or module-remap-source that has a master pointing to the sink's monitor.
Then I can write to that sink, and get data to show up in this virtual
microphone.
I've found that module-remap-source has a lower latency
than module-virtual-source, (~400ms lower it seems), but I don't have
any idea why. And more generally -- what is the difference between
these two modules? I looked at their source and also the git history,
but that didn't clear much up for me.
Also, is this the best way to make a low latency microphone? I have an
application that I want to send data to Chrome, with as low latency as
possible. Chrome operates directly with pulseaudio[0].
Thanks,
Chase
[0]
https://source.chromium.org/chromium/chromium/src/+/main:media/audio/pulse/audio_manager_pulse.cc
<https://source.chromium.org/chromium/chromium/src/+/main:media/audio/pulse/audio_manager_pulse.cc>
