Add mod_audio_fork to FreeSWITCH's build alongside libwebsockets
(which mod_audio_fork depends on).
mod_audio_fork is used by the built in transcription feature as
a way to extract L16 streams from FreeSWITCH via WebSockets for further
processing by arbitrary transcription servers.
For full details on mod_audio_fork itself, please check drachtio's
source repo: github.com/drachtio/drachtio-freeswitch-modules.git
A few cautionary tales about this one:
- The new patch (mod_audio_fork_build.patch) guarantees libwebsockets
is properly linked to FreeSWITCH and that mod_audio_fork is built as
well. That's because mod_audio_fork is not an upstream module.
- The patch _may_ introduce conflicts on FreeSWITCH bumps more easily
than the other patches we have. They shouldn't be too hard to adapt,
though.
- There's fine tuning to be done to FreeSWITCH's unit file regarding
mod_audio_fork's capabilities. Again: check drachtio's repo.
bbb-webrtc-sfu (and mediasoup) are running in the CFS scheduler which
means it has to compete with (much) lower priority tasks like
presentation conversion, recording processing, [...]
Since it encompasses an RTC application which also handles audio, it
should be _at least_ on the same scheduling policy as FS/bbb-html5 - and
that should be safer now with mediasoup which has a lower footprint
(and generates lower CPU noise overall).
This commit puts bbb-webrtc-sfu in the FIFO scheduling policy (same as
bbb-html5). Also bumps bbb-html5 nice level up to 18 and sets SFU to
nice 19 (so bbb-html5 has some advantage when push comes to shove).
This can be improved further by using per-process priorities in SFU.
Ideally we'd want mediasoup audio workers and mcs-core to be the same
priority as FS (so higher than bbb-html5), but the rest of them
(video/screen workers) to be the same or lower than bbb-html5. For
future reference:
- https://github.com/bigbluebutton/bbb-webrtc-sfu/commit/3e245122dfa155ecb77b536eeadac1e4607cee
- 66d443d204
Files are compressed on build, but gzip_static on isn't set on their
nginx route - so original files are being served, uncompressed.
This commit serves the previously compressed files instead (thus
reducing initial transfer size by ~1 MB).
Someone should look into whether serving compressed version of the rest
of assets makes sense - it probably does.
Still pending: fonts, locales, svgs, everything under resources, ...
