Latency: discuss and evaluate current test results

changed milestone to %1.0-alpha3 — Playful Platypus

assigned to @chrizz

mentioned in issue #55 (closed)

Just recorded a metronome click @60 BPM coming from my DAW patched through aura playout. Detected a latency of approx. 500ms - respecting some additional delay (~6ms roundtrip) caused by my personal audio interface.

I can't read much out of this image, could you explain to me what exactly your are showing here?

Sure, and also got some updates:

The clock signal is sent every second from an external, low-latency audio interface, according to a 60 BPM grid which is marked by the long grey lines on top.

The white lines below (blue background) is the delayed signal which is routed through the aura-setup and coming back to the external interface.

Got these results by running liquidsoap in different setups:

liquidsoap test (without docker): ~167ms
engine-core (without docker): ~235ms
aura-playout (using docker): ~443m

So after respecting some extra delay of ~5ms - due to the second audio interface - these values seem to be correct.

NB: this testing machine has poor hardware

One thing we should consider to test is the performance under the full load of aura-web and aura-playout. I will test this right away.

@kay_jointech do you have any tips on how we could improve the performance when running with docker/docker-compose? I was thinking about nice or ionice. Any experience or suggestions?

I run the full aura setup and got a delay of about 120ms. So this really depends on system requirements and system load. I do think we can live with the current results, surely there is room for improvement in the future - but for now this is good enough. Closing this issue and moving on to long(er) time testing.

Maybe we can run this again with our simplified docker-compose/liquidsoap test scripts and see if the latency is smaller?

Already started extending the test case we've discussed last Thu; we could schedule another meeting in the upcoming days...

I am free today, hit me up on Matrix if you want to discuss some details in person

On the question what delays are acceptable: The shorter the better for us. Let's try if we can improve the 500ms delay. To be honest for FREIRAD 0.5 seconds is something we can work with.

After considering the hardware and comparing our results, the delay seem to be acceptable for now; and to keep focusing on the sunny side: aura seems to work even on outdated machines with less than 500ms live-latency

I created a test setup myself with the following wiring:

flowchart TD
    A[Clock Sound] --> B[fa:fa-microphone Recording]
    A[Clock Sound] --> |line_in| C(Aura)
    C --> |line_out| B

Now I can check the delay on the recording machine by measuring the difference between the starting points of a distinct audio spike.

Docker compose test script

When using a simple liquidsoap test script in docker compose I get a difference of about 0,084s, so about 84ms. This looks promising!

Screenshot

AURA docker compose

When running aura-playout I get a difference of about 0,174s, or about 174ms. This is double the latency of the test script. My guess for the source of this would be the added complexity and the additional components running at the same time.

Screenshot

Great! So after considering the outdated hardware of our testing pc and some extra delay due to the second interface, these results seem to conform.

Did you choose aura-recorder for capturing the audio?

No I just used Audacity, any recording software would work I think since the delay I measured is not affected by any delays or latency the recording software would introduce.

added Doing P1 + 1 deleted label

closed

removed Doing label

marked this issue as related to #55 (closed)

changed the description

Latency: discuss and evaluate current test results

Designs

Child items ...

Activity

Docker compose test script

AURA docker compose