2 second delay of output

[epicfacethe3rd]

it's working fine, but there's a 2 second delay for the output for me, which makes it fairly impractical for daily use. is there a way to lower this delay at the cost of processing power/sampling rate?

[epicfacethe3rd]

admittedly this is more a quality of life improvement than an actual bug, the program works flawlessly

[ghost]

You can create a file at ~/.config/lyrebird/config.toml with the contents:

# Configuration file for Lyrebird
# The following parameters are configurable

# buffer_size = The buffer size to use for sox. Higher = better quality, at
# the cost of higher latency. Default value is 1024

[[config]]
buffer_size = 1024

This will change the buffer size which in turn will affect latency and quality. You can play around the perfect buffer size for you, 1024 is the default so anything lower should reduce the latency you're seeing.

[epicfacethe3rd]

as low as 64 i still get no latency improvement. 32 brings it down by about half a second, but it cannot go any lower

[megabytesofrem]

Sadly, since Sox (and therefore Lyrebird) uses Pulseaudio rather than JACK there is going to be some expected latency. Try reducing it to 256 or something like @harrego said.

[hankshill]

Using virtual sinks to run my desktop audio through Lyrebird, I'm able to get as low as 15ms latency. This is not voice, just running applications through Lyrebird and listening on the "Lyrebird output" channel. Here's how I did it:

Start and enable Lyrebird

Create a sink TESTING and add the slave alsa_output.pci-0000_0b_00.4.analog-stereo which is referencing my on-board audio controller. You can get your on-board audio controller with the first command (the second line is the output):

% pacmd list sinks | grep "Default sink"
Default sink name: alsa_output.pci-0000_0b_00.4.analog-stereo
% pacmd load-module module-combine-sink sink_name="TESTING" slaves="alsa_output.pci-0000_0b_00.4.analog-stereo"

I now have two new audio output devices: "Simultaneous output to [my audio controller]" and "Lyrebird Output." I also have one new input device: "Lyrebird virtual input"

I'm not very familiar with PulseAudio so I did the following in pavucontrol GUI:

SoX: "Simultaneous output to [my audio controller]
Firefox: "Lyrebird Output"
https://ibb.co/TBMbVdV

SoX: record from Lyrebird Virtual Input
https://ibb.co/2g5VfFx

I set my default recording device to "Lyrebird Virtual Input" and my playback device to "Lyrebird Output"
https://ibb.co/p1dQvh3

I'm not sure if the following is relevant, but I also edited the following values in /etc/pulse/daemon.conf because it reduces the latency when using PulseAudio for virtual machines

 default-fragments = 3
 default-fragment-size-msec = 5

I do not know why this works as I'm not very versed in PulseAudio or SoX. I just I thought it would be funny to put some music through Lyrebird and tinkered with Pulse settings until it worked.

I'm sharing this in case someone knows how to adapt my procedure to produce low latency voice output.

[megabytesofrem]

Interesting, thanks for the share.

[coreybruce]

There is pretty bad latency on some, maybe it would be better to switch to jack

[ghost]

@hankshill This is great thanks for sharing! My assumption has always been that the latency comes from SoX but I'll take a closer look and try and add this to the main code.

[ghost]

@coreybruce I do like jack and have played a little with it but my understanding, and please correct me if I'm wrong, is that it cannot be used with Pulse without hacking on most systems. Choosing Pulse for Lyrebird is deliberate since Discord (large chat app) only supports Pulse and video game support is good for Pulse.

[coreybruce]

I actually am not sure on that part but it might be something worth looking into :P

[Absolucy]

@harrego @coreybruce Apparently Pipewire is becoming more mainstream now, and it's somewhat similar to Jack with the simplicity of PulseAudio (plus actual compat layers so that PulseAudio apps work with it), maybe that's something to look into?

[ghost]

@aspenluxxxy Pipewire is definitely interesting an something to look into after v2, this is being discussed in #62

[ghost]

Some news on this: the C rewrite of Lyrebird (v2) drops the delay to a couple of milliseconds. This will most likely be resolved in the new C version.

[quantumac]

I've found after I get everything set up for VRChat, if I disable Lyrebird and then re-enable it, the delay is significantly reduced. There is still a delay, but not 2 seconds. More like a tenth of a second or so. Not sure why.

[BenStigsen]

Any news on the C rewrite of v2?

[dragonfi]

I've found after I get everything set up for VRChat, if I disable Lyrebird and then re-enable it, the delay is significantly reduced. There is still a delay, but not 2 seconds. More like a tenth of a second or so. Not sure why.

I experimented a bit (by monitoring the Lyrebird Virtual Input with VLC).

buffer_size did not help much, if at all.
Disabling and restarting lyrebird sometimes produced 100-200msec latency, but mostly just stayed at 2s most of the time.

[Darkflib]

Sorry to bump an old thread, I am not 100% of the internals of pulseaudio and sox, but does pulse have the concept of a jitter buffer? I know that from my voip work, that sometimes jitter buffers can be quite large if you happen to get a latency spike on a connection.

Since this is internal to the system, you might try making the processes higher priority - either niceness or perhaps cgroups... you probably don't want to go the whole hog for realtime processes, it opens up a whole new can of worms...