[Гость MALLOY2]

нужен диск от техаса eXpressDSP Software and Development Tools Guided Tour точнее исходники кодеков GSM 06.10 GSM 06.60. А также любая инфо по этим кодекам заранее благодарен.

[Seishel 0]

Я думаю это стоит кучи денег и если их нет, то берётся стандарт и исходники пишутся самостоятельно, так например было у меня с кодеком G728, а например кодек G726 стоит 10000 и это только первый взнос и плюк проценты с каждой копии/канала...

[flashEl 0]

Исходники кодеков GSM 06.10 GSM 06.60 и др. можно взять на _ftp://ftp.3gpp.org/Specs/archive/06_series__

 

Это, конечно, не оптимизированный код для TI - простой C

[Seishel 0]

А не кто не подскажет где взять код для G726, G728, G729?????

[fontp 0]

А не кто не подскажет где взять код для G726, G728, G729?????

 

 

На какой процессор ;)

 

А так нигде ...

 

To MALLOY2

 

На какой процессор GSM ? На кой-какой я может и мог бы раскошелиться собственным ассемблерным кодом. На tms54

На adsp21xx AD всегда раздавала ассемблерный код GSM

Изменено 15 февраля, 2006 пользователем fontp

[Seishel 0]

Ну вообщето пока нужны для TMS320С54, а в дальнейшем бы желательно для С64....

[fontp 0]

Ну вообщето пока нужны для TMS320С54, а в дальнейшем бы желательно для С64....

 

 

Для ТМS54 я могу подарить авторский ;-) ассемблерный код многоканального GSM 6.10

Есть у меня также самодельный ассемблерный код G729 и G723.1 (примерно 20 мипс на канал каждый),

но дарить я его не буду, я его могу продать кому надо в виде объектных библиотек или исходников.

Будет дорого, но в несколько раз дешевле, чем, например, во СПИРИТе и у остальных. Если что обращайтесь.

Или можете сделать сами за те же деньги Чистый реентерабельный ассемблерный код, безо всяких Экспрессов. Понятное дело всё битэкзактно.

 

Насчёт TMS64 - моё имхо такое, что кодирование на ассемблере обычно не нужно (за исключением может G728, для которого из-за коротких циклов этот процессор вообще неадекватен со своими конвейерами, код 728 на любом 6х будет тормозом как не кодируй). TMS64 за 150$ настолько мощный процессор, что если вы поставите G723.1 (не говоря уже про G729) референтный код на него, реализовав библиотеку ETSI в виде инлайн функций и чуть-чуть подработав критические модули поиска по кодовым книгам прагмами - вы сразу получите каналов так 30 в С-коде, а больше обычно и не нужно (Я повозился в своё время с 62-ым (250Мгц) и получил за несколько недель 16 каналов). Ведь решается обычно конкретная задача, а не чтоб было просто круто донельзя. А конкретная задача - это обычно шина. Такова современная реальность - не нужно решать задач слишком хорошо, а нужно решать в нужный срок и в рамках бюджета. Закон Паретто и всё такое, вы знаете.

 

Сейчас у меня в процессе G723.1 на Блэкфин. 30 каналов риалтайма уже есть на процессоре 750Мгц за 40$. План такой - дожать до процессора 600 Мгц (за 15$) и окончательно похоронить всех парней, кто наклепал кодеров на шину E1 на TMS6x :tongue:

G729 А-B на 30 каналов понятное дело даётся легко на 600 мегагерцовом процессоре.

 

Вообще, с появлением tms6x и особенно BF времена когда DSP-шные фирмы произвольно диктовали цены телекоммуционным, похоже, заканчиваются

 

Что касается старинных ADPCM кодеков, в том числе 726 - они все есть в Сети в виде С-кода и они настолько просты, что ничто не мешает побыстрому их перегнать в ассемблер. Например G726 (1)

 

http://trac.beirdo.ca/projects/nuvtools/fi...c/g726.c?rev=34

 

я сразу нашёл гуглом по ключевым словам : G726 source download free

 

Или вы имеете в виду G726.2 AMR-WB ? Так это экзотика, референтный код есть в Сети (или на СD от ITU-T), а с реализацией туго. Стандарт достаточно новый, и на устаревший 54-ый процессор врядли кто его захочет вообще делать

Изменено 18 февраля, 2006 пользователем fontp

[Seishel 0]

маленький вопрос в догонку, почему ты перешёл с TMS на BF при реалицации кодеков???

[fontp 0]

маленький вопрос в догонку, почему ты перешёл с TMS на BF при реалицации кодеков???

 

;) Стоимость при достаточном быстродействии и возможности не кодировать весь проект на ассемблере

 

На tms62 никак не получалось 30 каналов. Приличная полностью ассемблерная реализация того же SPIRITа затрачивает около 10 Мипс, а это 25 каналов. А это практически совсем ничем не лучше пятнадцати. Да и вообще, процессоры серии 6х стоят особняком. Выпиливание ассемблерных конвейеров для сколько-нибудь большого приложения - это уже не программистская задача, а ассемблерное программирование процессора серии 6х - это проектирование аппаратных конвейеров,

причём конвейер открытый - длительность выполнения команд различна и программист должен это учитывать. Кто пробовал - знает, проектирование на 3-х мерных таблицах или графах. Лично я не в восторге, я привык программы писать, а не рисовать в 3-х-мерном пространстве. Много не нарисуешь ;)

Потом появился 64-ый процессор, но он слишком дорогой для нормальных комерческих приложений.

Поскольку это старшая серия у TI, надеяться на снижение цен на них не приходится.

 

Компилятор С (C++) для BF достаточно эффективны чтобы кодировать в ассемблере только критические модули (это относится в ещё большей степени к tms6х c их ортогональной архитектурой, но мне не нравится цена). Писать весь проект на ассемблере достаточно трудоёмкая задача. Время + затраты. Прямая альтернатива BF - процессоры 55-ой серии, они соразмерны по быстродействию и стоимости. Но 55-ый процессор берёт архитектурой, а BF - частотой. На 55-ом процессоре опять придётся весь проект выпиливать на ассемблере, соответственно трудоёмкость кодирования значительно выше. Конечно, если задача серверная то нужен ОМАР c АРМОМ, и BF не катит. Или как делали раньше - к BF нужен хост. Если на один процессор запихнуть операционку как сейчас делают многие, то для DSP не останется ресурсов.

Но для клиентских устройств - BF самое то. Кажется, он так и позиционируется.

 

Мне так кажется, на самом деле с 55-ым процессором я не работал.

Изменено 20 февраля, 2006 пользователем fontp

[dxp 39]

Конечно, если задача серверная то нужен ОМАР c АРМОМ, и BF не катит. Или как делали раньше - к BF нужен хост. Если на один процессор запихнуть операционку как сейчас делают многие, то для DSP не останется ресурсов.

А если BF двуядренный взять - на одном ядре ОСь вращается, на другом ЦОС. Кажись, кто-то на телесиськах с полгода-год назад именно про такой вариант и говорил. По эффективности кода сам BF АРМу, насколько знаю, не уступает.

[bav 0]

В CCS Си компилятор достаточно эффективно оптимизирует код. Вначале, когда начинал изучать C64x, вставлял asm, сейчас полностью программа на С++. Занимаюсь обработкой видео в реалтайме.

Разница в производительности программы на asm и С не большая (плюс/минус пару процентов), а время на разработку плюс/минус месяц. В С главное, грамотно написать прогу. Иногда "поменяв строчки местами" (конечно, сохраняя суть алгоритма :) ) скрость возрастает/падает на десятки процентов (примеры привести не могу, проводл эксперименты, когда гонял компилятор, проверял его свойства :smile3046: )

[Seishel 0]

Просто не все алгоритмы расчитаны на то что бы обрабатывались большие массивы данных, где эффектно выглядит много конвеерная архитектура Техаса, по этому всё таки иногда приходится и с асмом возится....

[bav 0]

в смысле? Приведите пример.

не ужели используя асм Вы получаете бооольшой выигрыш по производительности. Особенно не испульзуя конвеер? зачем тогда DSP?

[Seishel 0]

Ну конвейер конечно используется, а алгоритм могу привести только G728 там длинна векторов всего в 5 членов, причём при перекрёстном перемножении вообще приходится производить постоянно инициализацию умножения...

[bav 0]

с жатием звука я конечно не работал. Спорить не буду. Но неужели С не делает "приходится производить постоянно инициализацию умножения..."? или я что-то не так понял?