You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: