Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC?] @udio channels #91

Open
SoniEx2 opened this issue Jan 24, 2017 · 0 comments
Open

[RFC?] @udio channels #91

SoniEx2 opened this issue Jan 24, 2017 · 0 comments

Comments

@SoniEx2
Copy link

SoniEx2 commented Jan 24, 2017

Channels with @ prefix should be audio channels. Each PRIVMSG contains audio data (TODO figure out bitrate, see below), base128-encoded opus.

This does mean PRIVMSGs in @ channels aren't UTF-8, but I don't remember that ever being an issue. Base64 gives us roughly 2700 bits per PRIVMSG, while base128 gives us roughly 3150 - this is a huge improvement for audio quality.

Clients should NOT send PRIVMSGs when the mic is inactive/muted.

There should be an umode to block audio channel PRIVMSG from being sent to the client. This is to save server bandwidth without forcing the client to /part the channel when muted.

Since this is primarily speech-oriented, we can get away with a rate limit of 4 PRIVMSG / second, which is a fairly common rate limit on IRC networks. This gives us a theoretical limit of around 12600 bits/s. In practice, since the PRIVMSG limit would be shared between audio and text channels, clients would need to implement QoS and send 2 to 3 PRIVMSG / second to an audio channel, and use the remaining 1 PRIVMSG for text. This gives us a bandwidth between 6300 bits / second to 9450 bits / second.

Alternatively, we could use variable bitrate and the client would degrade sound quality when sending large amounts of PRIVMSGs.

Clients shouldn't let the user speak in multiple audio channels at the same time. Clients shouldn't let the user join multiple audio channels at the same time. However, bridge bots would benefit from these, so the server shouldn't disallow them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant