В выходные я постараюсь довести новый комплект драйверов до beta-версии, и протестировать его было бы очень кстати. В новых драйверах с телефонией должно быть получше, но для начала нужно сделать скидку на beta-версию. Как только будет готово я размещу архив на http://www.cronyx.ru/software/

Но хочу предупредить - "телефонный" режим на адаптерах серии Tau-PCI (не путать с Tau-PCI/32) всегда будет "хромать". Дело в том, что первоначально Tau-PCI предназначалась только для приёма-передачи HDLC. Позже, по просьбе клиента, была сделана доработка для приёма RAW-данных, потом для передачи. Но из-за аппаратных особенностей Tau-PCI обмен в "телефонном" режиме происходит только блоками по 1024 байт, что соответствует интервалу 4 ms. Как правило, это слишком много для realtime/телефонных применений (для сравнения в zaptel этот интервал равен 1 ms).

Весь zaptel-зависимый стек asterisk (zaptel, libpri, libmfcr2, chan_unicall, chan_zap) рассчитан на обработку данных порциями по 256 байт (1 ms). При использовании Tau-PCI, с точки зрения zaptel-стека, данные приходят "пачками" 4 по 256 байт за раз. Из-за этого не только увеличивается задержка, но возникают проблемы с обработкой (отказ эхо-подавителей, искажения при транзите E1-asterisk-E1 и т.д.).

С Tau-PCI/32 таких проблем нет, поэтому мы рекомендуем для использования с astersk именно эту серию адаптеров. Основной минус - с помощью одного адаптера (как Tau-PCI/32-Lite, так и не "Lite") можно завести только один поток E1.

искажения при транзите побеждены же в последней верии от рика.

эхо по умолчанию давится с задержкой до 128/8000=16ms, максимальная задержка была 32ms, в svn убрали это ограничение. так что задержка в 4ms неприятна - но не смертельна.

вопрос - кросс-коннектор в tau будет использоваться в новой версии zaptel-драйверов для dacs? если да - задержка все-равно получится в 4ms?

насчет одного потока e1 в tau32 - опять же если кросс-коннектор будет использоваться, то это вполне разумное ограничение - транзит во многих случаях можно пустить напрямую, через asterisk же только сигнализация пройдет и нетранзитные разговоры пойдут.
вопрос только в том, куда девать имеющиеся tau ;)

Я не в курсе что Роман (rik@) решил проблему с "транзитом", уже написал ему, посмотрим что скажет. В процессе доработки DDK и нового комплекта драйверов для Tau-PCI всплыли неадекватности (несовместимость с тестами), возможно что это следы этих экспериментов. Но еще несколько лет назад было выяснено, что Infineon 20534 DSSC4 подглючивает в этом режиме.

С dacs возникли сложности - как миниум мне сейчас негде это проверять/отлаживать. Уже запланирована покупка двух б/у мини-АТС с поддержкой как pri, так и mfcr2. Но пока их нет (в ремонте), а самое главное нет времени на возню с их запуском и стыковкой с asterisk. Видимо я сделаю dacs уже после выхода нового комплекта драйверов (6.0), где-нибудь возле версии 6.1

Осталось добавить в tau32 аппаратную поддержку кодеков?

В tau32 добавляться что-либо уже не будет. Когда-то была предусмотрена возможность установки аппаратного кодека G.726/G.727/G.721 и т.д. (но не G.723 или G.729 a/b). Но это так и осталось не востребованным.

Реально нужным сейчас представляется наличие качественного эхо-подавления и кодеков класса G.729a/b, G.723, Speex, iLBC, аппаратная поддержка T.38. Но за G.729 и G.723 необходимо делать лицензионные отчисления (бумажной волокиты еще больше). А со Speex и iLBC другие проблемы - нет недорогих "одночиповых" решений, нужно ставить мощный DSP типа blackfin и самостоятельно разрабатывать для него firmware. Все это возможно, доступно и реализуемо, но очень сильно влияет на цену, так как по многим причинам мы не можем производить (и продавать) изделия десятками тысяч.

Поэтому сейчас идет разработка платы для PCI-66MHz в low-profile форм-факторе, на 1/2/4 канала E1 (три варианта исполнения) с опциональным эхо-подавлением. Причем эхо-подавитель будет один из лучших (128 ms, G.156, G.168 (1998, 2000, 2002) и с "advanced noise processing").

Идея установки аппаратных кодеков пока еще не похоронена окончательно. Поэтому можно (и нужно) обсуждать - что именно (из кодеков) и насколько нужно.

http://www.cronyx.ru/forum/?t=2073 ;)

Leo_YurievНо еще несколько лет назад было выяснено, что Infineon 20534 DSSC4 подглючивает в этом режиме.

может быть речь о чем-то другом? у меня tau работает с двумя потоками e1 в production ещё с прошлого года без каких-либо нареканий

Leo_YurievС dacs возникли сложности - как миниум мне сейчас негде это проверять/отлаживать. Уже запланирована покупка двух б/у мини-АТС с поддержкой как pri, так и mfcr2. Но пока их нет (в ремонте), а самое главное нет времени на возню с их запуском и стыковкой с asterisk.

запуск - может быть, а вот поднять pri в asterisk у меня получилась буквально в течении нескольких минут (при том, что я этот asterisk в первый раз поставил). chan_unicall просто не mainstream, поэтому подводных камней там больше

Leo_YurievПоэтому сейчас идет разработка платы для PCI-66MHz в low-profile форм-факторе, на 1/2/4 канала E1 (три варианта исполнения) с опциональным эхо-подавлением.

не боитесь опоздать?
помимо digium и sangoma есть куча мелких производителей, вот ещё один из россии нарисовался на ixbt: http://forum.ixbt.com/post.cgi?id=print:32:14708

вспомнилось - не знаю, что там sangoma ставит, digium начал ставить oct6100 с характеристиками, похожими на перечисленные вами

Как и обещал, драйвер сделал.
Добавлен во FreeBSD zaptel project
См: http://www.voip-info.org/wiki/view/FreeBSD+zaptel

CCS mode - работает, с CAS - траблы при разрыве физики канала.

по-моему предыдущее сообщение достойно выноса в отдельную тему, тем более что раздел соответствующий на форуме есть.

ps: у меня freebsd нет и работа * под линухом меня вполне устраивает, но как владелец tau-pci спрошу - а что, действительно только tau32 поддерживается?

Если имеется ввиду имено работа с zaptel стеком - то да, драйвер работает в этом режиме с tau32/pci, tau32/pci-Lite.

Для Tau-PCI/xE1 перерабатывали DDK и он вообще небыл доступен, следовательно и поддержку zaptel было достаточно сложно сделать...