Closed chaolue closed 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...
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.
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)
@booss, no still same issue with both devices (amd64 and aarch64), with the '* 2' removed.
And you have the exact same backtrace ? (could you provide the new backtrace please).
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)
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....
I pushed a potential fix in the branch pulseaudio_latency. Could you try it please ?
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?
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.
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.
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.
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.
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.
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