Использование Speex для сжатия речи, как заточить под свою платформу Опции

[frag666]

Имеется прекрасный Open Sourse проект Speex.Сжимает речь.Есть исходники.Под Windows получилось скомпилить и запустить,всё отлично работает.Теперь стоит задача использовать этот кодек на TMS320C28xx.Если я правильно понимаю,мне достаточно добавить все исходные файлы и библеотеки Speex в свой прект и всё будет работать?Если кто работал с этим кодеком поделитесь опытом.

[fontp]

Имеется прекрасный Open Sourse проект Speex.Сжимает речь.Есть исходники.Под Windows получилось скомпилить и запустить,всё отлично работает.Теперь стоит задача использовать этот кодек на TMS320C28xx.Если я правильно понимаю,мне достаточно добавить все исходные файлы и библеотеки Speex в свой прект и всё будет работать?Если кто работал с этим кодеком поделитесь опытом.

Работать-то должно если типы данных окажутся соответствующими в файле speex_typedef.h
Но оптимизацию-то по быстродействию if any придётся самому проводить. Код имеет варианты оптимизации для tms54x, tms55x, tms6x, BF53х, arm4, arm5... Но не для tms28х.

Если нужно быстродействие подтягивать - лучше всего посмотреть, как это сделано для BF. Для наиболее критических модулей по быстродействию сделаны инлайновые ассемблерные вставки прямо в h-файлах. Нужно делать такие-же для тех -же модулей
Прагмы ещё могут помочь

[frag666]

Спасибо.
Попробую взять сорсы для С55 и переделать под С28.

[Itch]

Надеюсь автор топика не обидится, если я здесь задам свой вопрос.
Вобщем захотелось мне заиметь speex под BF531, но вот компилировать я его собираюсь с помощью VDSP, а не gcc. При этом студия ругается на ошибку С1101, не нравятся ей ассемблер в одном из файлов. Кто-нибудь преодолевал эту проблему? Поиск на [Speex-dev] ничего вразумительного не дал.

[frag666]

Надеюсь автор топика не обидится, если я здесь задам свой вопрос.
Вобщем захотелось мне заиметь speex под BF531, но вот компилировать я его собираюсь с помощью VDSP, а не gcc. При этом студия ругается на ошибку С1101, не нравятся ей ассемблер в одном из файлов. Кто-нибудь преодолевал эту проблему? Поиск на [Speex-dev] ничего вразумительного не дал.

Не обижусь.Мне интересно всё,что связано с Speex .Такую же ошибку и мне выдал мой комилятор,когда я хотел скомпилировать проект для C55 под С28.Потом начал ковырятся в исходники и нашёл эту строку.Там всего одна иструкция на асме написана.Вот сейчас узнаю,что она делает.

[fontp]

Надеюсь автор топика не обидится, если я здесь задам свой вопрос.
Вобщем захотелось мне заиметь speex под BF531, но вот компилировать я его собираюсь с помощью VDSP, а не gcc. При этом студия ругается на ошибку С1101, не нравятся ей ассемблер в одном из файлов. Кто-нибудь преодолевал эту проблему? Поиск на [Speex-dev] ничего вразумительного не дал.

Так у VDSP в отличие от gcc нет таких констрейнтов как "m", "W" другие буквы используются, другая конвенция

http://gcc.gnu.org/onlinedocs/gcc/Simple-C...ple-Constraints
Они ещё и машинно независимы, а значит не очень эффективны

Препроцессор надо писать для подстановки :-)

speex есть у AD в составе мультимедийного SDK. Нужно там смотреть подправили ли индусы констрейнты под VDSP

[Itch]

Сейчас нашел на сайте ADI описание этой проблемы:

Using "n" asm constraint results in compiler error
Prognosis: Fixed in Update 5.0 Base Release
Using the "n" constraint in an inline asm results in a compiler error when compiling with the Blackfin VDSP++ compiler.
The effect of the constraint should be to define a literal as an asm statement operand.
The same effect can be achieved by using the literal directly in the asm statement template.
So for example:
asm("// %0 " : : "n"(256) : ); // fails to compile
could be replaced by the following to workaround the problem:
asm("// 256 " : : : );

Т.е. проблема вроде решена в VDSP 5.0. Я не шарю в ассемблере для BF, может кто-нибудь более опытный скажет, как например переписать следущий листинг:

Код

__asm__  (
         "P0 = 15;\n\t"
         "R0 = %1;\n\t"
         "R1 = %2;\n\t"
         //"R0 = R0 + R1;\n\t"
         "R0 <<= 1;\n\t"
         "DIVS (R0, R1);\n\t"
         "LOOP divide%= LC0 = P0;\n\t"
         "LOOP_BEGIN divide%=;\n\t"
            "DIVQ (R0, R1);\n\t"
         "LOOP_END divide%=;\n\t"
         "R0 = R0.L;\n\t"
         "%0 = R0;\n\t"
   : "=m" (res)
   : "m" (a), "m" (bb)
   : "P0", "R0", "R1", "cc");

VDSP ругается здесь на строчку : "=m" (res)

[fontp]

Сейчас нашел на сайте ADI описание этой проблемы:

Т.е. проблема вроде решена в VDSP 5.0. Я не шарю в ассемблере для BF, может кто-нибудь более опытный скажет, как например переписать следущий листинг:

Код

__asm__  (
         "P0 = 15;\n\t"
         "R0 = %1;\n\t"
         "R1 = %2;\n\t"
         //"R0 = R0 + R1;\n\t"
         "R0 <<= 1;\n\t"
         "DIVS (R0, R1);\n\t"
         "LOOP divide%= LC0 = P0;\n\t"
         "LOOP_BEGIN divide%=;\n\t"
            "DIVQ (R0, R1);\n\t"
         "LOOP_END divide%=;\n\t"
         "R0 = R0.L;\n\t"
         "%0 = R0;\n\t"
   : "=m" (res)
   : "m" (a), "m" (bb)
   : "P0", "R0", "R1", "cc");

VDSP ругается здесь на строчку : "=m" (res)

Никак она не решена. Это просто разные вещи. Не работали константы - ну заработали
Все буквы разные для VDSP и gcc и часто даже смыслы разные

Для "m" надо писать "memory", если это временная переменная. Если входная или выходная -
нужно переписывать на косвенную или индексную адресацию сам код ([%0]) меняя констрейнты
на "a"
А что писать для разных W или "1"?
Практически это большая ручная работа - переписать эти ассемблерные вставки

Кроме того этот код не очень эффективен, он не знает какие апаратные регистры использовать.
Машинно-независимый ассемблер :-)
Надо смотреть мультимедийный SDK, там или разгребли констрейнты Gcc или отключили эту оптимизацию нафик и пускают С-код - вполне возможно что по быстродействию оптимизирующий компилятор VDSP выиграет у "машинно-независимого ассемблера" gcc :-)

[Itch]

Надо смотреть мультимедийный SDK, там или разгребли констрейнты Gcc или отключили эту оптимизацию нафик и пускают С-код

Ага, тоже вот думаю - нафиг этот асм, буду С пока использовать. Времени в обрез, надо проект делать, а уж потом разберемся (:

[fontp]

Ага, тоже вот думаю - нафиг этот асм, буду С пока использовать. Времени в обрез, надо проект делать, а уж потом разберемся (:

А скачайте мультимедийный SDK с сайта AD. В нём объявлен SPEEX, наверняка под VDSP, gcc они не поддерживают
По идее должны быть исходники, но кто его знает... Всего то ничего - 65Мб

http://www.analog.com/processors/platforms/msk.html
Только там на analog.com нужно сначала зарегистрироваться. Посмотрите и расскажете :-)

[Itch]

Скачал я этот SDK. Устанавливаться на студию июня 2006 года он отказывается, поэтому пришлось провести апгрейд до версии июля 2007. Встать то он встал, но вот студия перестала работать - на понравились ей старые лицензионные ключи Так что пришлось довольствоваться только исходниками... Индусы похоже хлеб свой отрабатывают исправно, т.к. ассемблерные версии функций действительно были переписаны, все констрейнты в основном были заменены на "d". Правда кое-где остались "m", которые у меня на старой студии от 06.2006 не компилировались. В Readme к SDK пишут, что тестировали его на июльской версии, т.е. видимо от 2007г. Фиг с ними, с "m", остальные функции вроде работают нормально. Кстати Speex там старый, 1.1.9 от мая 2005г.
Наконец то запустил я этот speex (: Сильно порадовало качество речи при режиме сжатия 0 ( 2400 kbps ) - речь можно понять без проблем, я думал будет намного хуже. Хотя еще надо смотреть, как это все будет при сильном внешнем шуме и т.п....

[Itch]

Да, все-таки не работает оптимизация Speex под ассемблер Blackfin в VDSP. Кодек, который идет с Multimedia SDK при компиляции использует только #define FIXED_POINT. Если включить BFIN_ASM, то не компилируется даже под студией версии 4.5 от 07.2007. Будем ждать VDSP 5.0...

[blackfin]

Будем ждать VDSP 5.0...

VDSP 5.0

[fontp]

Да, все-таки не работает оптимизация Speex под ассемблер Blackfin в VDSP. Кодек, который идет с Multimedia SDK при компиляции использует только #define FIXED_POINT. Если включить BFIN_ASM, то не компилируется даже под студией версии 4.5 от 07.2007. Будем ждать VDSP 5.0...

Так и было в предыдущих версиях SDK.
Причём не только констрейнты m не проходят. Там были явные ошибки с точки зрения VDSP. И в самих инструкциях, и в констрейнтах и с автоматической генерацией меток. Они потихоньку возятся, но оптимизацию при построении не включали никогда.
Где-то встречалась цифра про 15 каналов SPEEX по быстродействию с оптимизацией BFIN_ASM. Это 30-35 мипс на канал вместе с их эхоподавителем. Для demo столько и не надо. И не факт, что с VDSP 5_0 эта проблема будет решаться
С другой стороны, если понадобится кому реально speex, там не так много нужно исправить, ну не за день, конечно

[Itch]

VDSP 5.0

Имеется в виду "будем ждать лекарство". (^:
http://electronix.ru/forum/index.php?showtopic=36351

[Puzan]

...Мне интересно всё,что связано с Speex ...

А Вы не в курсе, какая производительность ARM7TDMI (ARMv4) нужна для сжатия речи (13 бит/8 кГц) speex'ом в реальном времени?

[Itch]

Точно про производительность не скажу, но натыкался в инете на резюме одного человека, который там утверждал, что втиснул Спикс в SAM7S, правда не помнью в какой именно, возможно в 32й.

[fontp]

Точно про производительность не скажу, но натыкался в инете на резюме одного человека, который там утверждал, что втиснул Спикс в SAM7S, правда не помнью в какой именно, возможно в 32й.

Dawid Rowe (автор) пишет в своём блоге
http://www.rowetel.com/blog/?p=6

We built on this work, reducing the complexity for the encode operation from about 40 MIPs to 23 MIPs. On a typical 500MHz Blackfin this means you can now run (500/23) = 21 Speex encoders in real time.

Т.е. данная ассемблерная оптимизация для Blackfin даёт двухкратное быстродействие. Для демонстрационных целей 40 мипс вполне достаточно. Естественно, что на VDSP++ можно сделать более шустрый код, поскольку известно, что SPEEX BF не вмещается во внутренней памяти и крутится в кеше - это раз, а два - оптимизатор С в VDSP++ заведомо более эффективный на сигнальных задачах.

Реализации для TI помедленнее (упоминаются цифры 25 + 4), поскольку кроме BF, в проекте присутствует кой-какая ассемблерная оптимизация только для ARM и Pentium MMX

Здесь обсуждается проблема совместимости констрейнтов gcc и vdsp. Это "родной" форум для speex
http://lists.xiph.org/pipermail/speex-dev/...une/005806.html

Не думаю, что авторы захотят портировать код на VDSP++ (хотя Dawid Rowe где-то и упоминает, что отладчик gdb его задолбал). Ещё более сомнительно, что разработчики VDSP++ будут подтягивать инлайновый ассемблер к стандарту gdb

[fontp]

Dawid Rowe (автор) пишет в своём блоге
http://www.rowetel.com/blog/?p=6

We built on this work, reducing the complexity for the encode operation from about 40 MIPs to 23 MIPs. On a typical 500MHz Blackfin this means you can now run (500/23) = 21 Speex encoders in real time.

Т.е. данная ассемблерная оптимизация для Blackfin даёт двухкратное быстродействие. Для демонстрационных целей 40 мипс вполне достаточно. Естественно, что на VDSP++ можно сделать более шустрый код, поскольку известно, что SPEEX BF не вмещается во внутренней памяти и крутится в кеше - это раз, а два - оптимизатор С в VDSP++ заведомо более эффективный на сигнальных задачах.

Реализации для TI помедленнее (упоминаются цифры 25 + 4), поскольку кроме BF, в проекте присутствует кой-какая ассемблерная оптимизация только для ARM и Pentium MMX

Здесь обсуждается проблема совместимости констрейнтов gcc и vdsp. Это "родной" форум для speex
http://lists.xiph.org/pipermail/speex-dev/...une/005806.html

Не думаю, что авторы захотят портировать код на VDSP++ (хотя Dawid Rowe где-то и упоминает, что отладчик gdb его задолбал). Ещё более сомнительно, что разработчики VDSP++ будут подтягивать инлайновый ассемблер к стандарту gdb

Проверено быстродействие в VDSP++. Без ассемблера быстродействие кода 25 + 3.5 мипс
С ассемблерными вставками можно получить с кодера 16 мипс