Erlang/elixir sample code for real time voice chat?

[mat-hek]

@zeroexcuses

• I understand the argument of “erlang has it’s roots in telephony, of course erlang/elixir is a great fit for this”
• I understand that voice chat is “basically just a router for udp packets, and elixir has great libraries for those”

Agreed

@zeroexcuses

1. For whatever reason, looking at old threads, I am not finding a good simple example:

Playing with media is not as simple as you’d expect, unfortunately

@zeroexcuses

Is there any example of using erlang/elixir to build a simple voice chat server

We’re building WebRTC SFU server, that handles both audio and video. We made it work, but It’s still experimental and extensively developed.

@RudManusachi

My understanding of such project is: elixir/erlang is a great fit of “orchestration”… connecting people, setting the pipeline of encoding/decoding/streaming via web/etc. But underneath those encoder/decoder are still delegated to some low level libs.

That’s mostly true, though Elixir is very convenient for handling protocols and containers too, because of its good support for binaries and bitstrings. Heavy, numerical computations are indeed delegated to low-level, mostly C libraries, but since it’s done via simple NIFs or C nodes, it doesn’t involve

@zeroexcuses

offloading the work to some other server

@dimitarvp

Not sure there’s any perfectly justified reason but at least my thinking would be that the BEAM has GC pauses (albeit very short and are per-process which should limit their impact) that can affect latency – which would be a deal-breaker in audio streaming.

If you deal with latencies around 2ms, then it may be a problem - haven’t tested. But for usual media streaming it’s good enough. People even write streaming apps in Go, that has stop-the-world GC - that one happens to be problematic though, AFAIK.

@dimitarvp

But from my side I’d opt for an Elixir orchestrator and a Rust implementation beneath just to be sure if the app scales it will still work without lagging.

We didn’t have time for big optimizations of Membrane yet, neither we used it with OTP 24 JIT. Anyway, it’ll probably never be as fast as if we used Rust or C. Membrane focuses rather on reliability, scalability and maintainability.