https://github.com/chayleaf/ihatelatency

low-latency audio streaming server/client
https://github.com/chayleaf/ihatelatency

Last synced: 5 days ago
JSON representation

low-latency audio streaming server/client

• Host: GitHub
• URL: https://github.com/chayleaf/ihatelatency
• Owner: chayleaf
• License: mit
• Created: 2024-10-23T11:06:45.000Z (23 days ago)
• Default Branch: master
• Last Pushed: 2024-10-24T17:31:55.000Z (22 days ago)
• Last Synced: 2024-10-25T16:13:03.751Z (21 days ago)
• Language: Rust
• Size: 25.4 KB
• Stars: 1
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: COPYING

Awesome Lists containing this project

README

        
# ihatelatency

This is a project I made for streaming audio from my PC to my phone,

because other solutions were kinda annoying to deal with.

Currently, playback is handled via `cpal` for maximum compatibility, but

recording is handled via `pipewire` for minimum latency.

Usage:

```shell

# on the device to stream audio from (server)

pactl load-module module-null-sink sink_name=remote

ihatelatency -l -a  record -n remote

# on the device to stream audio to (client)

ihatelatency -a  play

```

Roles can be switched, the recording device is allowed to be the one to

connect to the playing server. The `-u` flag may be added to use UDP

instead of TCP. Note that for UDP the playback device must be the

server. Using UDP is currently recommended.

For TCP, the playback buffersize is autoadjusted based on how stable

the network is. The algorithm is pretty stupid, though I plan to improve

it at some point. If you set the env var `RUST_LOG=trace`, the program

will print all xruns, and also constantly print the current buffer size.

This allows you to pick a buffer size by yourself - you can then pass it

with the `-s` flag for the `play` command. The bigger the buffer, the

higher the latency and the less xruns. With UDP, autoadjustment is

disabled (packet loss acts as autoadjustment instead).

Currently, `s16le`, `48000`, stereo is assumed, but it should be fairly

trivial to add support to sample rate selection (or sending it on

connection, except for UDP).

Also, currently the server can only handle one client at a time since I

don't have a need for streaming audio to multiple devices (and receiving

audio from multiple devices is its own can of worms).

You may actually use other programs as players, like this:

```shell

# udp (most of these flags aren't required but may or may not decrease latency)

ffplay -nodisp -ac 2 -ar 48000 -analyzeduration 0 -probesize 32 -fflags nobuffer -flags low_delay -fflags discardcorrupt -f s16le -i "udp://?listen=1"

# udp

nc -u -l 0.0.0.0  | mpv --demuxer=rawaudio --no-cache --untimed --no-demuxer-thread --demuxer-rawaudio-rate=48000 -

```

Or as recorders, like this:

```shell

# udp

ffmpeg -f pulse -i  -ac 2 -f s16le udp://

# tcp (please don't send pcm via udp netcat)

parec --format=s16le -d  --latency-msec=1 --rate=48000 | nc  

```

Nonetheless, I guarantee that my program is at least as good as other

programs in terms of latency, the only other thing you can tune is

network settings, or sound server settings ([here's a post explaining how

to do it for PulseAudio](https://juho.tykkala.fi/Pulseaudio-and-latency))