Это библиотека для использования на их DSP. Но эти DSP еще нужно на что-то собрать

и сколько каналов смогут энкодить эти dsp?

сколько заплатите - сколько и смогут )

Ну не факт. Может какие-нибудь программируемые fpga/asic существуют

политика скорее всего как у всех

программные asic )))))))))))))))))?

я знаю такой - ffmpeg с либой lame )

ну так я и говорю, на ксеонах дешевле

https://github.com/toots/shine вот более быстрая реализация

ох... что-то я сомневаюсь что в 15 раз так уж и быстрее

Я предложил не луа, а mrcp. Lua только для распределения задач между серверами. Точнее, только для генерации случайного числа - номера сервера записи. По-моему, Вы не очень поняли суть предложения.
Фрисвич умеет транслировать rtp-stream по mrcp протоколу. unimrcp сервер умеет писать в файл. Простейшее изменения demo-record плагина для unimrcp сервера (подключение lame или shine библиотеки) даёт возможность писать полученное прямо в mp3-файл. Дальше поднимаем столько серверов, сколько нам нужно и распределяем между ними нагрузку равномерно

как lua сможет при генерации числа опираться на доступность сервиса? как вы гарантируете что все сервисы будут нагружены равномерно при псевдо-рандоме ?

1. Она и не должна, обработку ошибок нужно делать на стороне ФС.
2. Это гарантирует математическая статистика, наука такая ))))))

2. она как бы гарантирует при больших значениях )))) но никак не гарантирует что подряд у вас не выпадет одно и то же число

1. даже стало интересно - как же фс будет знать что стримит ртп в пустоту?

1. Эм... Идите в доку ) там про это подробно )
2. Проблема одновременного кодирования на маленьком числе звонков как бы не возникнет

1. ок

2. при 20 одновременных выйдет распеределение 15 и 5 на два сервера. вполне реально

а что при 20 звонках есть какие то проблемы производительности?

20 одновременно машина с ФС закодирует сама и не заметит