Подбираем информацию для разработки след. устройства: С одной стороны ethernet, желательно 100-мегабитный, с другой стороны - телефонная линия. Со стороны ethernet-а бегают звуковые пакеты в прикладном протоколе, надстроенном над TCP/IP. Звук сжат вокодером (соответственно звуковой трафик на устройство - небольшой). Далее, прикладной протокол оговарвает пакеты управления, которыми можно управлять устройством. Например, выдать приказ набрать какой-либо номер телефона. Устройство (или несколько устройств, или даже много устройств, например 30-100 шт.) взаимодействует с хостом - компьютером. Хост может выдать приказ устройству набрать, например номер телефона. Когда устройство наберет этот, указанный в управляющем пакете, номер телефона, и со стороны абонентской линии кто-то возьмёт трубку, то устройство рапортует соему хосту, что оно дозвонилось, и тот, в свою очередь, начинает посылать звуковые пакеты в формате вокодера на устройство (и далее к человеку с той стороны телефонной линии) и, соответственно, принимать от устройства звуковые пакеты - речь человека.

Предполагается использовать Cortex-M3 от Luminary Micro (LM3S8970 и 50 МГц тактовая) в качестве контроллера и какой-нибудь SLIC со встроенным кодеком (например Si3216 от SiLabs) для сопряжения с телефонной линией.
1) Вопрос в том, потянет ли этот контроллер вокодирование и девокодирование и 100-Мбитный ethernet. Вокодирование включает в себя всякие там функции типа преобразования фурье. Или надо брать что-нибудь помощнее, например 9-ый ARM или каклй-нибудь TMS типа С6424
2) Какой SLIC более подходящий для наших линий? Их делают, как выразился один мой друг, все кому не лень, а проблема эха остаётся.

Вот с этой проблемы и начните свои рассуждения о необходимой мощности процессора, ибо ни один SLIC не будет заниматься компенсацией эха возникшего из-за ЗАДЕРЖКИ В ВАШЕМ IP. Его дело обеспечить переход на двухпроводку при задержке практически стремящейся к 0 (несколько раз, ну десятков раз по 125us). Ну а мегабитность Ethernet и нагрузка от него вообще никакого значения не имеет при Ваших потоках. Все остальное пишите и моделируете.

А зачем выдумывать новый стандарт VoIP?

Мы уходим немного в сторону.

С этим я совершенно согласен. Судя по структурной схеме "слика" Si3216 в ней после кодека стоит аналоговый циркулятор (да и, по-моему, иначе быть не может), который развязывает двухпроводку на четырехпроводку.
Т.е. вы хотите сказать, что можно брать любой SLIC и он обеспечит функции циркулятора (т.е. не пропустит голос компьютера с выхода кодека на вход кодека, а подавит его на много децибелл). Но показатели у разных сликов разные, значит что-то из них лучше, а что-то хуже, опять же играет роль импеданс линии (выходное сопротивление слика должно уметь согласовываться с импедансом линии (иначе будут шумы)).

Здесь под эхом мы понимаем, наверное, разные вещи. Если нет, то поясните. Я имею в виду чисто аналоговое эхо из-за плохих характеристик циркулятора и шумов из-за несогласованности с линией. Вы, по-видимому, имеете в виду эхо, когда, кто-то, говоря по телефону по через IP, произносит слово "алё" и через секунду слышит сам себя.

Специфика нашей связи в том, что она, во-первых, смплексная (а это значит, что когда говорит компьютер, то человек сказать уже ничего не может, т.е. его разговор заканчивается на выходе кодека, данные которого игнорируются. Когда компьютер перестаёт говорить, то голос человека начинает восприниматься из кодека, преобразовываться в звуковые пакеты и отправляться в хост. По-этому проблема эха, как таковая, не существует. Я спросил только затем, что может, кто-то имеет опыт и скажет, что для наших линий более походящие такие-то слики, т.к. подстраиваются под наш импеданс и сами по себе имеют хорошие характеристики). Во-вторых путь голосового пакета - очень короткий, этот голосовой пакет выйдет из хоста, попадёт в другой, рядом стоящий эфирный компьютер и уйдёт в радиоэфир, либо из хоста в маршрутизатор, далее в выделенную E0, далее в маршрутизатор, далее в эфирный компьютер и в эфир. Предполагаем, что задержка не большая.

У меня простой вопрос - Кортекс сможет сжать/разжать MP3

Как мне это дело промоделировать? Посчитать в Keil-е такты сколько уйдёт на вокодирование? Мне кажется это будет слишком приблизительно. Всё равно так или иначе надо покупать kit. А хотелось бы узнать принципиально - верное это решение или нет.

Мы его не выдумываем. Он есть. Это стандартный вокодер, стандартные пакеты. Для достаточно специфичеких целей. Мы их только "сами" укладываем на TCP/IP, чтобы состыковать их передачу между компьютерами.

Любой SLIC может и должен быть подстроен под линию, в том числе и под "вашу" российскую Характеристики заложены издревле MKKT они все "хорошие" и никто их по понятным причинам "лучше", чем требуется не делает. А "хуже" сертифицирующие органы не пропустят на телефонные сети общего пользования.

Расшифруйте аббревиатуру SLIC и сами ответьте на свой вопрос.

Я - одинаковые, ибо наличие эха определяется работой эхокомпенсатора в вашей голове. Компенсатор "настроен" на определенный диапазон как уровней, так и задержек. Выход за эти пределы - эхо.

Для меня слик в данном случае, НЕ более чем интерфейс с телефонной линией.

Давайте отойдём от эха и от SLIC-а.
50-МГц-овый Кортекс сможет в риал-тайме отработать с mp3?

Ну MP3 для телефонной линии явно не тот выбор, а вот Speex влезет на асме писанный, но загрузит по полной, но опятьже все еще зависит от настроек сжатия и качества. Посмотрите на библиотеку Speex от ST для Cortex http://www.st.com/stonline/products/literature/an/14910.pdf

Спасибо за инфу. MP3 - это показатель трудоёмкости. Верхняя грань. Наш вокодер значительно проще. Он реализован под TMS320VC55xx на 50 МГц-ах работает вполне прилично. 300- 3400Гц - даёт поток 9.6 кбит/с. Но у 55-ых нет ethernet-а. А 64-ые - это как из пушки по воробъям. Поэтому и ищем более простое решение.

Если вопрос только в наличии ethernet-а, то может имеет смысл просто прикрутить к TMS внешний контроллер ethernet? Или если на одной плате установлено несколько TMS поставить один ARM со встроенным ethernet контроллером который будет обеспечивать операции приема/передачи пакетов.

Алгоритм вокодера реализован с фиксированной или плавающей точкой?

С фиксированной.

Этот вариант очень интересен тем, что можно на одной плате реализовать несколько телефонных интерфейсов с одним езернетом.

что-то у меня сомнения в том, что кортекс на 50МГц потянет real-time сжатие в какой-нибудь G.726

это вам не c mp3 играться!

Здесь созрело такое решение: взять Кортекс в качестве шлюза, взять один VC5509A для вокодера и навесить на TMS несколько SLIC-ов SI3216. (Можно их повесить хоть до восьми). У Кортекса удобный интерфейс с TMS-ом (там два SSI, здесь один McBSP), TMS - очень удобно соединится со SLIC-ами (задействуются ещё два McBSP - один на SPI, другой на кодеки в мультиканальном режиме). И дальше всё зависит от быстродействия 55-ого. Мне думается, что 4 телефонных канала на 180-МГцах он потянет, а может и больше. Спасибо всем, кто участвовал.

С натугом может и потянет. Если ARM7 @48Mhz тянет MP3, а у него в отличие от cortex'a нет аппаратного делителя.

Но я думаю - нефиг там жать - надо взять G.711 и все дела.
Жмет пусть эфирный комп, там трафик актуален, а для Fast Ethernet'a зачем заморачиваться?

насколько я исследовал тему - должен довольно легко справится.
Helix декодер для АРМа (он кстати очень вылизан в плане скорости) говорит что надо 30 МГц АРМ7ТДМи или около того,
по другим источникам LPC2148 тянет MP3 с 50% загрузкой.
Да, речь по-моему шла о 128 кбс стриме.