Полная версия этой страницы: Использование Speex для сжатия речи
Форум разработчиков электроники ELECTRONIX.ru > Цифровая обработка сигналов - ЦОС (DSP) > Алгоритмы ЦОС (DSP)
Имеется прекрасный Open Sourse проект Speex.Сжимает речь.Есть исходники.Под Windows получилось скомпилить и запустить,всё отлично работает.Теперь стоит задача использовать этот кодек на TMS320C28xx.Если я правильно понимаю,мне достаточно добавить все исходные файлы и библеотеки Speex в свой прект и всё будет работать?Если кто работал с этим кодеком поделитесь опытом.
Цитата(frag666 @ Sep 6 2007, 10:23) 
Имеется прекрасный Open Sourse проект Speex.Сжимает речь.Есть исходники.Под Windows получилось скомпилить и запустить,всё отлично работает.Теперь стоит задача использовать этот кодек на TMS320C28xx.Если я правильно понимаю,мне достаточно добавить все исходные файлы и библеотеки Speex в свой прект и всё будет работать?Если кто работал с этим кодеком поделитесь опытом.
Работать-то должно если типы данных окажутся соответствующими в файле speex_typedef.h
Но оптимизацию-то по быстродействию if any придётся самому проводить. Код имеет варианты оптимизации для tms54x, tms55x, tms6x, BF53х, arm4, arm5... Но не для tms28х.
Если нужно быстродействие подтягивать - лучше всего посмотреть, как это сделано для BF. Для наиболее критических модулей по быстродействию сделаны инлайновые ассемблерные вставки прямо в h-файлах. Нужно делать такие-же для тех -же модулей
Прагмы ещё могут помочь
Спасибо.
Попробую взять сорсы для С55 и переделать под С28.
Попробую взять сорсы для С55 и переделать под С28.
Надеюсь автор топика не обидится, если я здесь задам свой вопрос.
Вобщем захотелось мне заиметь speex под BF531, но вот компилировать я его собираюсь с помощью VDSP, а не gcc. При этом студия ругается на ошибку С1101, не нравятся ей ассемблер в одном из файлов. Кто-нибудь преодолевал эту проблему? Поиск на [Speex-dev] ничего вразумительного не дал.
Вобщем захотелось мне заиметь speex под BF531, но вот компилировать я его собираюсь с помощью VDSP, а не gcc. При этом студия ругается на ошибку С1101, не нравятся ей ассемблер в одном из файлов. Кто-нибудь преодолевал эту проблему? Поиск на [Speex-dev] ничего вразумительного не дал.
Цитата(Itch @ Sep 6 2007, 20:51)
Надеюсь автор топика не обидится, если я здесь задам свой вопрос.
Вобщем захотелось мне заиметь speex под BF531, но вот компилировать я его собираюсь с помощью VDSP, а не gcc. При этом студия ругается на ошибку С1101, не нравятся ей ассемблер в одном из файлов. Кто-нибудь преодолевал эту проблему? Поиск на [Speex-dev] ничего вразумительного не дал.
Вобщем захотелось мне заиметь speex под BF531, но вот компилировать я его собираюсь с помощью VDSP, а не gcc. При этом студия ругается на ошибку С1101, не нравятся ей ассемблер в одном из файлов. Кто-нибудь преодолевал эту проблему? Поиск на [Speex-dev] ничего вразумительного не дал.
Не обижусь.Мне интересно всё,что связано с Speex
.Такую же ошибку и мне выдал мой комилятор,когда я хотел скомпилировать проект для C55 под С28.Потом начал ковырятся в исходники и нашёл эту строку.Там всего одна иструкция на асме написана.Вот сейчас узнаю,что она делает.
Цитата(Itch @ Sep 6 2007, 21:51)
Надеюсь автор топика не обидится, если я здесь задам свой вопрос.
Вобщем захотелось мне заиметь speex под BF531, но вот компилировать я его собираюсь с помощью VDSP, а не gcc. При этом студия ругается на ошибку С1101, не нравятся ей ассемблер в одном из файлов. Кто-нибудь преодолевал эту проблему? Поиск на [Speex-dev] ничего вразумительного не дал.
Вобщем захотелось мне заиметь 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
Сейчас нашел на сайте ADI описание этой проблемы:
Т.е. проблема вроде решена в VDSP 5.0. Я не шарю в ассемблере для BF, может кто-нибудь более опытный скажет, как например переписать следущий листинг:
VDSP ругается здесь на строчку : "=m" (res)
Цитата
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 " : : : );
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");
"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)
Цитата(Itch @ Sep 7 2007, 11:57)
Сейчас нашел на сайте ADI описание этой проблемы:
Т.е. проблема вроде решена в VDSP 5.0. Я не шарю в ассемблере для BF, может кто-нибудь более опытный скажет, как например переписать следущий листинг:
VDSP ругается здесь на строчку : "=m" (res)
Т.е. проблема вроде решена в 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");
"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 :-)
Цитата
Надо смотреть мультимедийный SDK, там или разгребли констрейнты Gcc или отключили эту оптимизацию нафик и пускают С-код
Ага, тоже вот думаю - нафиг этот асм, буду С пока использовать. Времени в обрез, надо проект делать, а уж потом разберемся (:
Цитата(Itch @ Sep 7 2007, 12:38)
Ага, тоже вот думаю - нафиг этот асм, буду С пока использовать. Времени в обрез, надо проект делать, а уж потом разберемся (:
А скачайте мультимедийный SDK с сайта AD. В нём объявлен SPEEX, наверняка под VDSP, gcc они не поддерживают
По идее должны быть исходники, но кто его знает... Всего то ничего - 65Мб
http://www.analog.com/processors/platforms/msk.html
Только там на analog.com нужно сначала зарегистрироваться. Посмотрите и расскажете :-)
Скачал я этот SDK. Устанавливаться на студию июня 2006 года он отказывается, поэтому пришлось провести апгрейд до версии июля 2007. Встать то он встал, но вот студия перестала работать - на понравились ей старые лицензионные ключи 
Так что пришлось довольствоваться только исходниками... Индусы похоже хлеб свой отрабатывают исправно, т.к. ассемблерные версии функций действительно были переписаны, все констрейнты в основном были заменены на "d". Правда кое-где остались "m", которые у меня на старой студии от 06.2006 не компилировались. В Readme к SDK пишут, что тестировали его на июльской версии, т.е. видимо от 2007г. Фиг с ними, с "m", остальные функции вроде работают нормально. Кстати Speex там старый, 1.1.9 от мая 2005г.
Наконец то запустил я этот speex (: Сильно порадовало качество речи при режиме сжатия 0 ( 2400 kbps ) - речь можно понять без проблем, я думал будет намного хуже. Хотя еще надо смотреть, как это все будет при сильном внешнем шуме и т.п....
Так что пришлось довольствоваться только исходниками... Индусы похоже хлеб свой отрабатывают исправно, т.к. ассемблерные версии функций действительно были переписаны, все констрейнты в основном были заменены на "d". Правда кое-где остались "m", которые у меня на старой студии от 06.2006 не компилировались. В Readme к SDK пишут, что тестировали его на июльской версии, т.е. видимо от 2007г. Фиг с ними, с "m", остальные функции вроде работают нормально. Кстати Speex там старый, 1.1.9 от мая 2005г.Наконец то запустил я этот speex (: Сильно порадовало качество речи при режиме сжатия 0 ( 2400 kbps ) - речь можно понять без проблем, я думал будет намного хуже. Хотя еще надо смотреть, как это все будет при сильном внешнем шуме и т.п....
Да, все-таки не работает оптимизация Speex под ассемблер Blackfin в VDSP. Кодек, который идет с Multimedia SDK при компиляции использует только #define FIXED_POINT. Если включить BFIN_ASM, то не компилируется даже под студией версии 4.5 от 07.2007. Будем ждать VDSP 5.0...
Цитата(Itch @ Sep 10 2007, 12:44)
Да, все-таки не работает оптимизация 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, там не так много нужно исправить, ну не за день, конечно
Цитата(blackfin @ Sep 10 2007, 16:58)
Имеется в виду "будем ждать лекарство". (^:
http://electronix.ru/forum/index.php?showtopic=36351
Цитата(frag666 @ Sep 7 2007, 07:45)
...Мне интересно всё,что связано с Speex ...
...А Вы не в курсе, какая производительность ARM7TDMI (ARMv4) нужна для сжатия речи (13 бит/8 кГц) speex'ом в реальном времени?
Точно про производительность не скажу, но натыкался в инете на резюме одного человека, который там утверждал, что втиснул Спикс в SAM7S, правда не помнью в какой именно, возможно в 32й.
Цитата(Itch @ Sep 18 2007, 10:43)
Точно про производительность не скажу, но натыкался в инете на резюме одного человека, который там утверждал, что втиснул Спикс в 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 @ Sep 18 2007, 11:44)
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
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 мипс
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.