[BUG] latency is greater than, 2000ms at times #57

JamesOsborn-SE · 2024-03-20T21:41:46Z

Describe the bug
delay is greater than 2000ms at times making it unfit for watching a video or zoom meeting

To Reproduce
Steps to reproduce the behavior:
start server
start client
watch a video on the server

Expected behavior
I expect there to be a delay of 200ms or less

Screenshots
not applicable

Server (please complete the following information):

OS: Linux 6.7.9-arch1-1
GUI or CMD: CMD
Version: 0.0.17
network connection: wired Ethernet

Android (please complete the following information):

Device: FairPhone 3
OS: Android 13
Version: 0.0.17
network connection: Wi-Fi

Additional information
you might want to see how it's done in this project since it's multi-platform and has little latency

https://github.com/LizardByte/Sunshine/blob/nightly/src/audio.cpp

mkckr0 · 2024-03-21T08:58:17Z

I find two different things on the code:

Encode audio data to Opus format. It may decrease the network bandwidth.
Ajust the thread priority to high.

For the first, there is a existed feature request #33.

I'm not sure whether the network delay is the main reason. You can connect your phone to PC via USB tethering to test it.

For the second, I'll open a new feature request #60.

JamesOsborn-SE · 2024-03-25T23:50:14Z

USB tethering didn't work, but I connected my phone using Ethernet and there is still a noticeable delay

mkckr0 · 2024-03-26T05:01:57Z

#60 (comment)
#60 (comment)

sudo renice -n -20 $(pidof as-cmd)

You can try to set the process priority to test it.

mkckr0 · 2024-03-26T05:04:42Z

I remove the all zero check of blank PCM data, which may affect the performance.

audio-share/server-core/src/linux/audio_manager_impl.cpp

Lines 193 to 196 in b63b07b

    
           // if (std::all_of(begin, begin + count, [](const char e) { return e == 0; })) { 
        
           //     begin = nullptr; 
        
           //     count = 0; 
        
           // }

You can download the new as-cmd to test it.
https://github.com/mkckr0/audio-share/actions/runs/8430800638/artifacts/1358024281

JamesOsborn-SE · 2024-03-26T23:43:27Z

I remove the all zero check of blank PCM data, which may affect the performance.

audio-share/server-core/src/linux/audio_manager_impl.cpp

Lines 193 to 196 in b63b07b

// if (std::all_of(begin, begin + count, [](const char e) { return e == 0; })) {

// begin = nullptr;

// count = 0;

// }

You can download the new as-cmd to test it. https://github.com/mkckr0/audio-share/actions/runs/8430800638/artifacts/1358024281

Thanks for building that for me. Unfortunately, I do not notice any difference using renice or the new binary (with renice).

mkckr0 · 2024-03-27T02:42:20Z

I read the code of Sunshine again and find it use pulse-audio instead of pipewire.

I find a doc which may point out the problem.
https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_delay_or_audible_pop/crack_when_starting_playback

You can start playing first video. If there has been some sound, then start playing the second video and close first one. If second video has no delay, then the problem is clear. So you can try to use a virtual device https://github.com/mkckr0/audio-share#for-linux or follow the instruction of ArchLinux https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_delay_or_audible_pop/crack_when_starting_playback.

JamesOsborn-SE · 2024-03-27T16:43:19Z

I read the code of Sunshine again and find it use pulse-audio instead of pipewire.

I find a doc which may point out the problem. https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_delay_or_audible_pop/crack_when_starting_playback

You can start playing first video. If there has been some sound, then start playing the second video and close first one. If second video has no delay, then the problem is clear. So you can try to use a virtual device https://github.com/mkckr0/audio-share#for-linux or follow the instruction of ArchLinux https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_delay_or_audible_pop/crack_when_starting_playback.

I'm aware of this issue, this is for a delay when starting playback.

The delay I'm experiencing is a synchronicity issue. If the video shows a hammer hitting an anvil, then the strike isn't heard for 1–3 seconds. Maybe high latency is a better way to describe it? The ping time on Wi-Fi is only 14ms

I tried the virtual device and playing 2 overlapping videos just for curiosity and there is no noticeable change.

mkckr0 · 2024-03-29T06:07:11Z

I compiled a new as-cmd, which can show the stream time info.
https://github.com/mkckr0/audio-share/actions/runs/8477779993/artifacts/1369039023

as-cmd -b xxx.xxx.xxx.xxx -V

Output:

[2024-03-29 14:00:55.827] [trace] now:0 rate:0/0 ticks:0 delay:0 queued:0
[2024-03-29 14:00:56.827] [trace] now:10312842836090 rate:1/48000 ticks:47104 delay:0 queued:0
[2024-03-29 14:00:57.827] [trace] now:10313845502741 rate:1/48000 ticks:95232 delay:0 queued:0
[2024-03-29 14:00:58.830] [trace] now:10314848169392 rate:1/48000 ticks:143360 delay:0 queued:0
[2024-03-29 14:00:59.831] [trace] now:10315850836043 rate:1/48000 ticks:191488 delay:0 queued:0
[2024-03-29 14:01:00.834] [trace] now:10316853502694 rate:1/48000 ticks:239616 delay:0 queued:0
[2024-03-29 14:01:01.829] [trace] now:10317856169345 rate:1/48000 ticks:287744 delay:0 queued:0

The ticks should increase by about 48000. The delay should be always 0 if you use a virtual endpoint.

airi019 · 2024-04-02T17:34:29Z

#60 (comment) #60 (comment)
sudo renice -n -20 $(pidof as-cmd)
You can try to set the process priority to test it.

this is no good because as-cmd has 5 proccesses with the same name
I use htop to set nice value on all of them

Also using bluetooth on your android device introduces latency no matter what
make sure you're using headphone jack or built-in speaker

JamesOsborn-SE · 2024-04-02T19:40:18Z

#60 (comment) #60 (comment)
sudo renice -n -20 $(pidof as-cmd)
You can try to set the process priority to test it.
this is no good because as-cmd has 5 proccesses with the same name I use htop to set nice value on all of them

Also using bluetooth on your android device introduces latency no matter what make sure you're using headphone jack or built-in speaker

I reniced them all by hand and still no difference. The delay from network, bluetooth, CPU priority is not much of an issue when using sunshine and moonlight (maybe 150-500ms)

airi019 · 2024-04-02T20:18:52Z

#60 (comment) #60 (comment)
sudo renice -n -20 $(pidof as-cmd)
You can try to set the process priority to test it.
this is no good because as-cmd has 5 proccesses with the same name I use htop to set nice value on all of them
Also using bluetooth on your android device introduces latency no matter what make sure you're using headphone jack or built-in speaker
I reniced them all by hand and still no difference. The delay from network, bluetooth, CPU priority is not much of an issue when using sunshine and moonlight (maybe 150-500ms)

I'm using arch just like you so this doesn't make any sense
have you tried another android device?

JamesOsborn-SE · 2024-04-03T19:56:19Z

I'm using arch just like you so this doesn't make any sense have you tried another android device?

I've tried a different phone and steam deck. I don't know either it may be network but the delay with steam link and sunshine is negligible even with a video stream.

barolo · 2024-04-16T18:02:40Z

I've tested both audio-share and sunshine, and the latency of audio-share is at least 500ms higher when compared to Sunshine, no matter which tricks or means of transport are used. All that while Sunshine is also streaming video...

barolo · 2024-04-16T21:11:32Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html
There's an ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from remote mic].
In my testing it beats even sunshine.
Here's an android app https://github.com/roc-streaming/roc-droid

And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

airi019 · 2024-04-17T13:59:55Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid

And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!!
tested on debian testing and I almost can't tell diference between wired and this.
It's also cool that this is native os implementation

airi019 · 2024-04-18T01:43:31Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid
And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!! tested on debian testing and I almost can't tell diference between wired and this. It's also cool that this is native os implementation

I don't get it but it looks like this roc thing is missing on fedora 40 and 41.

we have to compile it from source

barolo · 2024-04-18T02:30:39Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid
And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!! tested on debian testing and I almost can't tell diference between wired and this. It's also cool that this is native os implementation

I don't get it but it looks like this roc thing is missing on fedora 40 and 41.

we have to compile it from source

I'm on Gentoo, so I just had to enable it and reinstall.
There's also this https://docs.pipewire.org/page_module_protocol_simple.html , which I haven't tried yet, there's android app for that too.

With Pipewire-ROC I like that it's pretty much always passively ready to stream and it's just a one button away to receive.

airi019 · 2024-04-18T10:38:09Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid
And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!! tested on debian testing and I almost can't tell diference between wired and this. It's also cool that this is native os implementation

I don't get it but it looks like this roc thing is missing on fedora 40 and 41.
we have to compile it from source

I'm on Gentoo, so I just had to enable it and reinstall. There's also this https://docs.pipewire.org/page_module_protocol_simple.html , which I haven't tried yet, there's android app for that too.

With Pipewire-ROC I like that it's pretty much always passively ready to stream and it's just a one button away to receive.

I was on gentoo too a while a ago before debian
Issue is that if it's not on fedora we're losing a lot a people
Even the build dependencies are missing I think
There is this "roc-toolkit-utils" package and that contains the roc-send command, so we could follow the raspberry pi tutorial, but I feel like it's easier if it's a pipewire module.

barolo · 2024-04-18T14:51:15Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid
And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!! tested on debian testing and I almost can't tell diference between wired and this. It's also cool that this is native os implementation

I don't get it but it looks like this roc thing is missing on fedora 40 and 41.
we have to compile it from source

I'm on Gentoo, so I just had to enable it and reinstall. There's also this https://docs.pipewire.org/page_module_protocol_simple.html , which I haven't tried yet, there's android app for that too.
With Pipewire-ROC I like that it's pretty much always passively ready to stream and it's just a one button away to receive.

I was on gentoo too a while a ago before debian Issue is that if it's not on fedora we're losing a lot a people Even the build dependencies are missing I think There is this "roc-toolkit-utils" package and that contains the roc-send command, so we could follow the raspberry pi tutorial, but I feel like it's easier if it's a pipewire module.

Arch seems to have issues too, with packaging.
That being said I've just tested protocol simple and it's bonkers, I get around 50ms~ latency OVER WI-FI,
definitely the lowest latency of them all. It's a bit confusing though, since it doesn't show as sink.

Config for it looks like this:

context.modules = [
{   name = libpipewire-module-protocol-simple
    args = {
        capture = true
        playback = false
        # node.latency = 1024/44100
        stream.capture.sink = true
        #playback.node = null
        #audio.rate = 44100
        #audio.format = S16
        #audio.channels = 2
        #audio.position = [ FL FR ]
        server.address = [
            "tcp:47111"
        ]
    }
}
]

and the app https://github.com/kaytat/SimpleProtocolPlayer

airi019 · 2024-04-18T15:19:35Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid
And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!! tested on debian testing and I almost can't tell diference between wired and this. It's also cool that this is native os implementation

I don't get it but it looks like this roc thing is missing on fedora 40 and 41.
we have to compile it from source

I'm on Gentoo, so I just had to enable it and reinstall. There's also this https://docs.pipewire.org/page_module_protocol_simple.html , which I haven't tried yet, there's android app for that too.
With Pipewire-ROC I like that it's pretty much always passively ready to stream and it's just a one button away to receive.

I was on gentoo too a while a ago before debian Issue is that if it's not on fedora we're losing a lot a people Even the build dependencies are missing I think There is this "roc-toolkit-utils" package and that contains the roc-send command, so we could follow the raspberry pi tutorial, but I feel like it's easier if it's a pipewire module.

Arch seems to have issues too, with packaging. That being said I've just tested protocol simple and it's bonkers, I get around 50ms~ latency OVER WI-FI, definitely the lowest latency of them all. It's a bit confusing though, since it doesn't show as sink.

Config for it looks like this:
context.modules = [
{   name = libpipewire-module-protocol-simple
    args = {
        capture = true
        playback = false
        # node.latency = 1024/44100
        stream.capture.sink = true
        #playback.node = null
        #audio.rate = 44100
        #audio.format = S16
        #audio.channels = 2
        #audio.position = [ FL FR ]
        server.address = [
            "tcp:47111"
        ]
    }
}
]
and the app https://github.com/kaytat/SimpleProtocolPlayer

I just installed arch linux and got roc running by installing this "pipewire-roc" package. It's on the official repo.
I'll try this simple protocol then report back

airi019 · 2024-04-18T15:42:28Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid
And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!! tested on debian testing and I almost can't tell diference between wired and this. It's also cool that this is native os implementation

I don't get it but it looks like this roc thing is missing on fedora 40 and 41.
we have to compile it from source

I'm on Gentoo, so I just had to enable it and reinstall. There's also this https://docs.pipewire.org/page_module_protocol_simple.html , which I haven't tried yet, there's android app for that too.
With Pipewire-ROC I like that it's pretty much always passively ready to stream and it's just a one button away to receive.

I was on gentoo too a while a ago before debian Issue is that if it's not on fedora we're losing a lot a people Even the build dependencies are missing I think There is this "roc-toolkit-utils" package and that contains the roc-send command, so we could follow the raspberry pi tutorial, but I feel like it's easier if it's a pipewire module.

Arch seems to have issues too, with packaging. That being said I've just tested protocol simple and it's bonkers, I get around 50ms~ latency OVER WI-FI, definitely the lowest latency of them all. It's a bit confusing though, since it doesn't show as sink.
Config for it looks like this:
context.modules = [
{   name = libpipewire-module-protocol-simple
    args = {
        capture = true
        playback = false
        # node.latency = 1024/44100
        stream.capture.sink = true
        #playback.node = null
        #audio.rate = 44100
        #audio.format = S16
        #audio.channels = 2
        #audio.position = [ FL FR ]
        server.address = [
            "tcp:47111"
        ]
    }
}
]
and the app https://github.com/kaytat/SimpleProtocolPlayer
I just installed arch linux and got roc running by installing this "pipewire-roc" package. It's on the official repo. I'll try this simple protocol then report back

Uhh I tested it with the youtube test in github link and it always beeps on the first black bar after the white one.
44100/11025 sample rate, mono and 50/10/1 ms tested.
It's the same latency for both simple protocol and roc.
I think roc is better because it sounds better

barolo · 2024-04-18T16:06:37Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid
And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!! tested on debian testing and I almost can't tell diference between wired and this. It's also cool that this is native os implementation

I don't get it but it looks like this roc thing is missing on fedora 40 and 41.
we have to compile it from source

I'm on Gentoo, so I just had to enable it and reinstall. There's also this https://docs.pipewire.org/page_module_protocol_simple.html , which I haven't tried yet, there's android app for that too.
With Pipewire-ROC I like that it's pretty much always passively ready to stream and it's just a one button away to receive.

I was on gentoo too a while a ago before debian Issue is that if it's not on fedora we're losing a lot a people Even the build dependencies are missing I think There is this "roc-toolkit-utils" package and that contains the roc-send command, so we could follow the raspberry pi tutorial, but I feel like it's easier if it's a pipewire module.

Arch seems to have issues too, with packaging. That being said I've just tested protocol simple and it's bonkers, I get around 50ms~ latency OVER WI-FI, definitely the lowest latency of them all. It's a bit confusing though, since it doesn't show as sink.
Config for it looks like this:
context.modules = [
{   name = libpipewire-module-protocol-simple
    args = {
        capture = true
        playback = false
        # node.latency = 1024/44100
        stream.capture.sink = true
        #playback.node = null
        #audio.rate = 44100
        #audio.format = S16
        #audio.channels = 2
        #audio.position = [ FL FR ]
        server.address = [
            "tcp:47111"
        ]
    }
}
]
and the app https://github.com/kaytat/SimpleProtocolPlayer
I just installed arch linux and got roc running by installing this "pipewire-roc" package. It's on the official repo. I'll try this simple protocol then report back
Uhh I tested it with the youtube test in github link and it always beeps on the first black bar after the white one. 44100/11025 sample rate, mono and 50/10/1 ms tested. It's the same latency for both simple protocol and roc. I think roc is better because it sounds better

That's quite weird, because Simple sounds much better for me, absolutely no issues, with defaults, where ROC sorta breaks/glitches when sound is paused/unpaused like it has to catch up.
What types of connection are you using?

Iy seems that You have almost no latency though, I get the beep at the first black bar on the magenta stripe, which is more than fine for me.

barolo · 2024-04-18T16:20:47Z

@airisama019 Changing anything made both sound and latency much worse for me, so try with defaults [and stereo] perhaps?

airi019 · 2024-04-18T16:22:11Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid
And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!! tested on debian testing and I almost can't tell diference between wired and this. It's also cool that this is native os implementation

I don't get it but it looks like this roc thing is missing on fedora 40 and 41.
we have to compile it from source

I'm on Gentoo, so I just had to enable it and reinstall. There's also this https://docs.pipewire.org/page_module_protocol_simple.html , which I haven't tried yet, there's android app for that too.
With Pipewire-ROC I like that it's pretty much always passively ready to stream and it's just a one button away to receive.

I was on gentoo too a while a ago before debian Issue is that if it's not on fedora we're losing a lot a people Even the build dependencies are missing I think There is this "roc-toolkit-utils" package and that contains the roc-send command, so we could follow the raspberry pi tutorial, but I feel like it's easier if it's a pipewire module.

Arch seems to have issues too, with packaging. That being said I've just tested protocol simple and it's bonkers, I get around 50ms~ latency OVER WI-FI, definitely the lowest latency of them all. It's a bit confusing though, since it doesn't show as sink.
Config for it looks like this:
context.modules = [
{   name = libpipewire-module-protocol-simple
    args = {
        capture = true
        playback = false
        # node.latency = 1024/44100
        stream.capture.sink = true
        #playback.node = null
        #audio.rate = 44100
        #audio.format = S16
        #audio.channels = 2
        #audio.position = [ FL FR ]
        server.address = [
            "tcp:47111"
        ]
    }
}
]
and the app https://github.com/kaytat/SimpleProtocolPlayer
I just installed arch linux and got roc running by installing this "pipewire-roc" package. It's on the official repo. I'll try this simple protocol then report back
Uhh I tested it with the youtube test in github link and it always beeps on the first black bar after the white one. 44100/11025 sample rate, mono and 50/10/1 ms tested. It's the same latency for both simple protocol and roc. I think roc is better because it sounds better
That's quite weird, because Simple sounds much better for me, absolutely no issues, with defaults, where ROC sorta breaks/glitches when sound is paused/unpaused like it has to catch up. What types of connection are you using?

Iy seems that You have almost no latency though, I get the beep at the first black bar on the magenta stripe, which is more than fine for me.

Idk dude I just use default ISP router with wifi 5ghz and this moto g5s phone that has headphone jack and lineageos.
Maybe it's the phone's drivers or something.
I heard a lot of complaints for newer phones and these guys fixed it with magisk modules and such.
I'll try and test this on my android TV and see if latency is worse.
It's probably gonna be better since it's running on ethernet

airi019 · 2024-04-18T16:32:52Z

@airisama019 Changing anything made both sound and latency much worse for me, so try with defaults [and stereo] perhaps?

I tried default settings and it was the same result

airi019 · 2024-04-18T16:34:02Z

I've also discovered this https://docs.pipewire.org/page_module_roc_sink.html There's ultra low latency protocol called ROC in pipewire, for over the network audio streaming [both ways, also from the remote mic]. In my testing it beats even sunshine. Here's an android app https://github.com/roc-streaming/roc-droid
And guides [quite simple] : https://gavv.net/articles/roc-tutorial-0.2/:

awesome!!! tested on debian testing and I almost can't tell diference between wired and this. It's also cool that this is native os implementation

I don't get it but it looks like this roc thing is missing on fedora 40 and 41.
we have to compile it from source

I'm on Gentoo, so I just had to enable it and reinstall. There's also this https://docs.pipewire.org/page_module_protocol_simple.html , which I haven't tried yet, there's android app for that too.
With Pipewire-ROC I like that it's pretty much always passively ready to stream and it's just a one button away to receive.

I was on gentoo too a while a ago before debian Issue is that if it's not on fedora we're losing a lot a people Even the build dependencies are missing I think There is this "roc-toolkit-utils" package and that contains the roc-send command, so we could follow the raspberry pi tutorial, but I feel like it's easier if it's a pipewire module.

Arch seems to have issues too, with packaging. That being said I've just tested protocol simple and it's bonkers, I get around 50ms~ latency OVER WI-FI, definitely the lowest latency of them all. It's a bit confusing though, since it doesn't show as sink.
Config for it looks like this:
context.modules = [
{   name = libpipewire-module-protocol-simple
    args = {
        capture = true
        playback = false
        # node.latency = 1024/44100
        stream.capture.sink = true
        #playback.node = null
        #audio.rate = 44100
        #audio.format = S16
        #audio.channels = 2
        #audio.position = [ FL FR ]
        server.address = [
            "tcp:47111"
        ]
    }
}
]
and the app https://github.com/kaytat/SimpleProtocolPlayer
I just installed arch linux and got roc running by installing this "pipewire-roc" package. It's on the official repo. I'll try this simple protocol then report back
Uhh I tested it with the youtube test in github link and it always beeps on the first black bar after the white one. 44100/11025 sample rate, mono and 50/10/1 ms tested. It's the same latency for both simple protocol and roc. I think roc is better because it sounds better
That's quite weird, because Simple sounds much better for me, absolutely no issues, with defaults, where ROC sorta breaks/glitches when sound is paused/unpaused like it has to catch up. What types of connection are you using?
Iy seems that You have almost no latency though, I get the beep at the first black bar on the magenta stripe, which is more than fine for me.
Idk dude I just use default ISP router with wifi 5ghz and this moto g5s phone that has headphone jack and lineageos. Maybe it's the phone's drivers or something. I heard a lot of complaints for newer phones and these guys fixed it with magisk modules and such. I'll try and test this on my android TV and see if latency is worse. It's probably gonna be better since it's running on ethernet

Yeah I tried it on Android TV running on Ethernet and It beeps on magenta bar just like yours.
So this is device driver issue for sure.
@JamesOsborn-SE close the issue. This is beyond @mkckr0 control.

barolo · 2024-04-18T16:43:34Z

@airisama019 also, I've just tried Simple while tethered, only with performance mode checked in the app, 48khz/stereo [that's what my system outputs so no conversion], and the beep comes from my phone at the same time as from the speakers.

airi019 · 2024-04-18T16:46:44Z

@airisama019 also, I've just tried Simple while tethered, only with performance mode checked in the app, 48khz/stereo [that's what my system outputs so no conversion], and the beep comes from my phone at the same time as from the speakers.

nice, that's closer to a solution then.

So, for wifi minimal latency, Basically you a android device launched with android 8 or less as per a certain magisk module description.

barolo · 2024-04-18T16:49:00Z

@airisama019 also, I've just tried Simple while tethered, only with performance mode checked in the app, 48khz/stereo [that's what my system outputs so no conversion], and the beep comes from my phone at the same time as from the speakers.

nice, that's closer to a solution then.

So, for wifi minimal latency, Basically you a android device launched with android 8 or less as per a certain magisk module description.

I'm using stock, unrooted A13 that came with zenfone 8 though.

airi019 · 2024-04-18T16:49:44Z

@airisama019 also, I've just tried Simple while tethered, only with performance mode checked in the app, 48khz/stereo [that's what my system outputs so no conversion], and the beep comes from my phone at the same time as from the speakers.

nice, that's closer to a solution then.
So, for wifi minimal latency, Basically you a android device launched with android 8 or less as per a certain magisk module description.

I'm using stock, unrooted A13 that came with zenfone 8 though.

my Android TV comes with A11 so that's no good either

airi019 · 2024-04-18T16:50:14Z

teach me how to use tethering I haven't tried it yet.

barolo · 2024-04-18T16:54:00Z

teach me how to use tethering I haven't tried it yet.

When you connect your phone via usb , there will be a popup where you can switch it to tethering, your other device, TV or whatever will get a new IP from it which you'll use to connect directly to the phone. I'm not sure where you can check the IP on TV, usually I do it via termux app, ifconfig command.

airi019 · 2024-04-18T16:55:54Z

yeah I got one here 192.168.88.61

airi019 · 2024-04-18T16:56:57Z

ok so roc app does know that ip

airi019 · 2024-04-18T16:59:25Z

yeah it's beeping right on the white bar now

airi019 · 2024-04-18T17:01:18Z

but tethering kinda beats the point of this I think
I like this stuff because I don't have to worry about tripping on the cable or breaking anything

airi019 · 2024-04-18T17:01:59Z

and it's faster than bluetooth

barolo · 2024-04-18T17:03:03Z

but tethering kinda beats the point of this I think I like this stuff because I don't have to worry about tripping on the cable or breaking anything

It all depends on your intended use. I get ya

airi019 · 2024-04-18T17:06:36Z

@barolo hey if I get an IP then why can't I use the PC's internet on the phone.

barolo · 2024-04-18T17:08:43Z

@barolo hey if I get an IP then why can't I use the PC's internet on the phone.

I'm a bit confused by your setup right now, so it's hard for me to say.

airi019 · 2024-04-18T17:09:27Z

@barolo hey if I get an IP then why can't I use the PC's internet on the phone.

I'm a bit confused by your setup right now, so it's hard for me to say.

I had to turn wifi off in order for roc app to change the IP so this is kinda of a bummer

airi019 · 2024-04-18T17:11:08Z

I'm doing tethering on the phone not android tv

airi019 · 2024-04-18T17:29:43Z

@barolo you're right about simple protocol not crackling on pause video
Maybe I'll just use that instead

airi019 · 2024-04-18T17:33:13Z

lol simple protocol with tethering beeps on the first black bar in the green stripe

airi019 · 2024-04-18T17:55:08Z

yeah, simple protocol has lower latency on android TV wifi as well. Instead of magenta stripe, it beeps right on the white bar

JamesOsborn-SE · 2024-04-19T22:33:08Z

JamesOsborn-SE close the issue. This is beyond @mkckr0 control.
I'm not sure if that's true, so I'll let mkckr0 make that decision.

barolo · 2024-04-20T02:48:40Z

JamesOsborn-SE close the issue. This is beyond @mkckr0 control.
I'm not sure if that's true, so I'll let mkckr0 make that decision.

As evident, there are inbuilt protocols in pipewire [they all come from pulseaudio apparently] which all result in much lower latency. So it might be useful to @mkckr0
I don't think that it is actually possible to go much lower than simple protocol, due to physics, The latency is so low that I'm comfortable with watching movie via my hearing devices connected to my phone on wi-fi network [and no, they cannot be connected directly]

airi019 · 2024-04-20T14:53:29Z

JamesOsborn-SE close the issue. This is beyond @mkckr0 control.
I'm not sure if that's true, so I'll let mkckr0 make that decision.

As evident, there are inbuilt protocols in pipewire [they all come from pulseaudio apparently] which all result in much lower latency. So it might be useful to @mkckr0 I don't think that it is actually possible to go much lower than simple protocol, due to physics, The latency is so low that I'm comfortable with watching movie via my hearing devices connected to my phone on wi-fi network [and no, they cannot be connected directly]

what I'm trying to say is that what started this issue is different android devices having more latency than others and that is due to hardware differences and there's nothing you can do about that.

Whether audio-share can be further improved or not has nothing to do with this.

mkckr0 · 2024-04-28T02:52:43Z

@JamesOsborn-SE your problem may be caused by the capture format. Sunshine use s16le PCM format. Audio Share use f32le, which need conversion between integer and floating-point. It may affect the performance.

mkckr0 · 2024-11-23T04:07:03Z

@JamesOsborn-SE Audio Share can specify the audio format since v0.2.0. You can test it.

JamesOsborn-SE · 2024-11-24T19:28:11Z

I don't hear/see a difference between ENCODING_PCM_16BIT and ENCODING_PCM_FLOAT it's about 0.4 to 0.5 sec of lag.
Sunshine is about 0.2 to 0.3
roc-droid isn't working for me atm. If I can test it I'll update

mkckr0 · 2024-11-25T03:53:50Z

This may be still a performance problem. But I can do nothing until I find some clues.

gauravyad69 · 2025-01-05T18:07:44Z

The latency seems to go down with encoding (lower bit lower latency), also the higher the buffer scale, the higher the latency, i was able to match your 2000ms latency with 10x buffer scale and 24bit int

airi019 · 2025-01-05T21:23:51Z

I don't hear/see a difference between ENCODING_PCM_16BIT and ENCODING_PCM_FLOAT it's about 0.4 to 0.5 sec of lag. Sunshine is about 0.2 to 0.3 roc-droid isn't working for me atm. If I can test it I'll update

roc-droid requires a specific pipewire setup and a separate package called pipewire-roc

JamesOsborn-SE added the bug Something isn't working label Mar 20, 2024

mkckr0 mentioned this issue Mar 21, 2024

[New Feature] Adjust the audio recording thread to High Priority #60

Closed

JamesOsborn-SE changed the title ~~[BUG] delay is greater than, 2000ms at times~~ [BUG] latency is greater than, 2000ms at times Mar 28, 2024

mkckr0 mentioned this issue Apr 28, 2024

[New Feature] Edit the capture PCM format(integer or float, bitwise, etc) #70

Closed

[BUG] latency is greater than, 2000ms at times #57

[BUG] latency is greater than, 2000ms at times #57

Comments

JamesOsborn-SE commented Mar 20, 2024

mkckr0 commented Mar 21, 2024

JamesOsborn-SE commented Mar 25, 2024

mkckr0 commented Mar 26, 2024

mkckr0 commented Mar 26, 2024

JamesOsborn-SE commented Mar 26, 2024

mkckr0 commented Mar 27, 2024 • edited Loading

JamesOsborn-SE commented Mar 27, 2024

mkckr0 commented Mar 29, 2024

airi019 commented Apr 2, 2024

JamesOsborn-SE commented Apr 2, 2024

airi019 commented Apr 2, 2024

JamesOsborn-SE commented Apr 3, 2024

barolo commented Apr 16, 2024

barolo commented Apr 16, 2024 • edited Loading

airi019 commented Apr 17, 2024

airi019 commented Apr 18, 2024

barolo commented Apr 18, 2024 • edited Loading

airi019 commented Apr 18, 2024

barolo commented Apr 18, 2024 • edited Loading

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

barolo commented Apr 18, 2024 • edited Loading

barolo commented Apr 18, 2024 • edited Loading

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024 • edited Loading

barolo commented Apr 18, 2024

airi019 commented Apr 18, 2024

barolo commented Apr 18, 2024

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

barolo commented Apr 18, 2024 • edited Loading

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

barolo commented Apr 18, 2024

airi019 commented Apr 18, 2024

barolo commented Apr 18, 2024

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

airi019 commented Apr 18, 2024

JamesOsborn-SE commented Apr 19, 2024

barolo commented Apr 20, 2024 • edited Loading

airi019 commented Apr 20, 2024 • edited Loading

mkckr0 commented Apr 28, 2024

mkckr0 commented Nov 23, 2024

JamesOsborn-SE commented Nov 24, 2024

mkckr0 commented Nov 25, 2024

gauravyad69 commented Jan 5, 2025 • edited Loading

airi019 commented Jan 5, 2025

mkckr0 commented Mar 27, 2024 •

edited

Loading

barolo commented Apr 16, 2024 •

edited

Loading

barolo commented Apr 18, 2024 •

edited

Loading

barolo commented Apr 18, 2024 •

edited

Loading

barolo commented Apr 18, 2024 •

edited

Loading

barolo commented Apr 18, 2024 •

edited

Loading

airi019 commented Apr 18, 2024 •

edited

Loading

barolo commented Apr 18, 2024 •

edited

Loading

barolo commented Apr 20, 2024 •

edited

Loading

airi019 commented Apr 20, 2024 •

edited

Loading

gauravyad69 commented Jan 5, 2025 •

edited

Loading