1. с микрофона поступает сигнал в буфер OS, по DMA
--- уже здесь может быть задержка порядка 1s
--- т.к. можно поставить буфер до 64k

2. приложение должно держать очередь буферов, куда
OS передает данные по мере поступления (целый буфер сразу)
--- 1-4k pcm, т.е порядка 0.1s, но все равно не 0.

3. дальше фрейм данных должен поступить на вход энкодера,
но тут есть варианты
а) чтение с микрофона встроено прямо в энкодер,
тогда задержка только на буфер энкодера 
(хз сколько там сейчас, 12k?)
--- т.е. +0.2s
б) реально практичней вариант с отдельным энкодером,
которому передается поток с микрофона
(типа mic | encode > out , как раньше было)
в таком случае mic пишет в поток ОС, для которого
тоже есть буфер порядка 64k (вероятно три, для
вывода и ввода ОС, и для ввода в программе)
--- +1s

4. Энкодер кодирует целый блок, на скорости допустим 10X
(без мультитредности запросто может быть и 2x)
--- +1-2s

5. Здесь, допустим, для упрощения, энкодер передает
стрим сразу декодеру через пайп
(mic | encode | decode | play)
--- тут уже задержка в данных zeus, ее трудно измерить
--- но даже при буфере 8k это будет ~2s

6. Дальше декодер читает данные, опять варианты
а) mzeus_lib напрямую получает входные данные
--- +1s
б) декодер кэширует блок, а потом декодирует
--- +2-3s на PC, +6-8s на iphone

7. Теперь плеер получает уже снова pcm
--- +0.2s
затем фрейм помещается в очередь буферов
(скажем, 16 в zstream)
---- +1s
затем фрейм передается в буфер ОС, а потом
по DMA в звуковуху
---- +0.1s

Итого получилось 11.3s при работе такого процесса
на быстром PC без передачи по сети
(но и без оптимизации по задержке)
С оптимизацией и интеграцией всего процесса в
одну программу, вероятно, можно получить задержку
порядка 3-5s с использованием zeus
(основной тормоз - блочное кодирование)

----------------------------

п.5 может работать и по сети, но с использованием
tcp-соединения задержка существенно вырастает -
порядка 64k данных может задерживаться в буферах
ОС и канале передачи, даже в практически идеальных
обстоятельствах.
В частности, при высокой загруженности канала и/или
ошибках передачи задержка может вырастать до минут,
пропорционально количеству "хопов" в маршруте.
--- 65536*8/70000 = ~7.5s (по битрейту)

Также, выше речь шла о прямой передаче точка-точка.
При использовании кастера же обычно требуется держать
в кэше минимум два блока (чтобы раздавать один, пока
читается второй), а лучше больше (чтобы было, что раздавать,
если данные задерживаются).
--- т.е. с кастером добавляется еще 10-20s задержки