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

[JamesOsborn-SE]

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]

I find two different things on the code:

1. Encode audio data to Opus format. It may decrease the network bandwidth.
2. 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]

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

[mkckr0]

#60 (comment)
#60 (comment)

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

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

[mkckr0]

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]

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]

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]

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]

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.

[airisama019]

#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]

#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)

[airisama019]

#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]

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]

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]

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/:

[airisama019]

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

[airisama019]

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]

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.

[airisama019]

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]

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

[airisama019]

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

[airisama019]

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]

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]

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

[airisama019]

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

[airisama019]

@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

[airisama019]

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]

@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.

[airisama019]

@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]

@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.

[airisama019]

@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

[airisama019]

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

[barolo]

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.

[airisama019]

yeah I got one here 192.168.88.61

[airisama019]

ok so roc app does know that ip

[airisama019]

yeah it's beeping right on the white bar now

[airisama019]

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

[airisama019]

and it's faster than bluetooth

[barolo]

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

[airisama019]

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

[barolo]

@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.

[airisama019]

@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

[airisama019]

I'm doing tethering on the phone not android tv

[airisama019]

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

[airisama019]

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

[airisama019]

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]

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]

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]

[airisama019]

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]

@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.