booss / rm8

M8 headless display - Rust
MIT License
53 stars 6 forks source link

Pulseaudio 2s (2000ms) audio delay #2

Closed chaolue closed 2 years ago

chaolue commented 2 years ago

Hi @booss

Really appreciate having an alternate option to m8c, and your additional menu items for controls, etc. I have an issue rm8 for both my laptop (amd64) and handheld (Odroid Go Advanced - aarch64) where pulseaudio creates a 2s delay on the audio - see requested latency for pulseaudio output.

1 source output(s) available.
    index: 0
    driver: <protocol-native.c>
    flags: DONT_MOVE 
    state: RUNNING
    source: 1 <alsa_input.usb-DirtyWave_M8_11417570-02.analog-stereo>
    volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
            balance 0.00
    muted: no
    current latency: 0.00 ms
    requested latency: 2000.00 ms
    sample spec: s16le 2ch 44100Hz
    channel map: front-left,front-right
                 Stereo
    resample method: (null)
    owner module: 9
    client: 3 <rm8-audio>
    properties:
        media.name = "Simple DirectMedia Layer"
        application.name = "rm8-audio"
        native-protocol.peer = "UNIX socket client"
        native-protocol.version = "33"
        application.process.id = "2523"
        application.process.user = "ark"
        application.process.host = "rgb10"
        application.process.binary = "rm8-audio"
        application.language = "C"
        application.process.machine_id = "82b7b768bc7742e6a5f379cd3c48dd47"
        module-stream-restore.id = "source-output-by-application-name:rm8-audio"

I was able to get around this by commenting out anything relating to audio from the src and just using jackd or pulseaudio loopback instead which has no delay, but would love to see it working through your app. How can I help?

Caleb

booss commented 2 years ago

Hi, Thank you for using rm8. I prepared a patch (see branch pulseaudio_latency) that might help understand if the latency comes from the number of samples used with the loopback. Otherwise, you can also try to change the priority of the process (using chrt for example). If you find something that works, feel free to submit a PR. If we find nothing, I'll try using OpenAL or something else...

chaolue commented 2 years ago

Hi @booss

I gave that a try but it looks like something isn't quite right...

librga:RGA_GET_VERSION:4.00,4.000000 
ctx=0x55807ccee0,ctx->rgaFd=3 
Rga built version:version:+2017-09-28 10:12:42 
thread '<unnamed>' panicked at 'source slice length (20000) does not match destination slice length (40000)', src/audio.rs:29:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted
ark@rgb10:~$ /roms/ports/m8c/rm8-pulse -smp 2000
librga:RGA_GET_VERSION:4.00,4.000000 
ctx=0x55cedb7ee0,ctx->rgaFd=3 
Rga built version:version:+2017-09-28 10:12:42 
thread '<unnamed>' panicked at 'source slice length (2000) does not match destination slice length (4000)', src/audio.rs:29:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted
ark@rgb10:~$ /roms/ports/m8c/rm8-pulse -smp 200
librga:RGA_GET_VERSION:4.00,4.000000 
ctx=0x557227eee0,ctx->rgaFd=3 
Rga built version:version:+2017-09-28 10:12:42 
thread '<unnamed>' panicked at 'source slice length (200) does not match destination slice length (400)', src/audio.rs:29:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted

Thanks.

booss commented 2 years ago

That's weird. It seemed to not panic with me. Could you try without multiplying spec.samples by 2 please ? (in src/audio.rs at line 51)

chaolue commented 2 years ago

@booss, no still same issue with both devices (amd64 and aarch64), with the '* 2' removed.

booss commented 2 years ago

And you have the exact same backtrace ? (could you provide the new backtrace please).

chaolue commented 2 years ago
calebh@zhulong:~/Apps/rm8$ RUST_BACKTRACE=1 ./target/release/rm8 -smp 200
thread '<unnamed>' panicked at 'source slice length (200) does not match destination slice length (400)', src/audio.rs:29:20
stack backtrace:
   0: rust_begin_unwind
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
   2: core::slice::<impl [T]>::copy_from_slice::len_mismatch_fail
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/slice/mod.rs:3209:13
   3: sdl2::audio::audio_callback_marshall
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: start_thread
             at /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477:8
   8: clone
             at /build/glibc-SzIz7B/glibc-2.31/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Aborted (core dumped)
booss commented 2 years ago

OK thanks, it seems to be the same problem: the source slice length is two times less than the destination slice. Beside the line I told you to change, I don't where else it could come from. It panics in src/audio.rs at line 29 (output.copy_from_slice) because the size given at line 51 is not right. Edit: I've been able to reproduce. Investigating....

booss commented 2 years ago

I pushed a potential fix in the branch pulseaudio_latency. Could you try it please ?

chaolue commented 2 years ago

Thanks @booss, it now let me customise the samples, but the pulseaudio output is still set to 2s latency on both my desktop and handheld. But when I tried it on my laptop (Linux Mint, the same as my desktop), the latency can be configured so that the latency is smaller. But the latency will still get set to 2s if set -smp to a specific value - so far testing, anything between -smp 1000 and -smp 1010 creates 2s latency. (My laptop also works fine without the -smp set). I haven't been able to find a -smp figure that works for my desktop or handheld. Will keep trying to find what might be different between each of the devices.

Do you have any suggested values for -smp?

booss commented 2 years ago

I don't sorry. I believe it works like the buffer settings on your sound card. Low numbers are good for latency but increase CPU usage.

chaolue commented 2 years ago

No problem. Thanks @booss. I'm still using it with the audio parts commented out. Maybe you could add a command line option to disable the built-in audio to use an external option - jackd, alsaloop or pulseaudio? But either way, awesome work.

booss commented 2 years ago

HI @chaolue, I merged the branch into master and added a new command line argument: -noaudio If you pass this flag, rm8 will not try to create the audio loopback. Thank you.

chaolue commented 2 years ago

Thanks @booss, works well. There are some command line errors about not being able to access the pulseaudio bits but doesn't stop it working.