Аудиокодек OGGVorbis на CM3, пробовал ли кто? Опции

[uk8amk]

Кодек Vorbis, страница разработчика:
http://xiph.org/vorbis/
Декодер Tremor с уменьшенными требованиями к ресурсам проца(целочисленные алгоритмы):
http://svn.xiph.org/branches/lowmem-branch/Tremor/
По возможностям что-то вроде MP3.

1)Интересует, справится ли CortexM3, какой-нибудь типичный STM32 на 20-70МГц?
Везде только общие слова, без хотя бы примерного футпринта по килобайтам ОЗУ,флеш и без MIPS-ов.
Хочу попробовать играть моно звук с качеством 30-60кбит. Пробовал Speex, но он хорош только для речи, звуки и подобие музыки - ужас.

2)И если кто-то вдруг пробовал, то наберусь наглости спросить пример(кусок) embed проекта.
Сам пытался натянуть Vorbis Tremor, но в файле codebook.c слишком много ошибок в Keil MDK сыплется. А вникнуть во все ребусы - знаний пока маловато.

Спасибо.

[SII]

Интересует, справится ли CortexM3, какой-нибудь типичный STM32 на 20-70МГц?

Не справится однозначно. Помнится, в своё время мой отец вынужден был перейти с 80486-100 на Пентиум-3 как раз из-за того, что на его ПК не хотели воспроизводиться MP3-файлы -- не хватало производительности. Понятно, что на ПК прилично времени под себя жрёт система и т.д. и т.п., однако и производительность 80486 при одинаковой тактовой частоте будет существенно выше, чем большинства ARMов (кроме разве что Cortex-A, и то вопрос дискуссионный). Дело тут в том, что на выполнение одного и того же действия для ARMа нужно больше команд, чем для IA-32 (например, вполне типичная операция -- инкремент или декремент переменной -- требует одной команды на IA-32 и трёх на ARM, причём в последнем случае ещё и свободный регистр для самой операции нужен, плюс нужно загрузить базовый адрес переменной в другой регистр, что может потребовать увеличения числа команд). В общем, думается, Cortex-M по своей производительности будет примерно соответствовать 80386 с близкой частотой.

Что касается целочисленной и вещественной арифметики, то в тех процессорах, где последняя поддерживается аппаратно, разницы в скорости их выполнения, по сути, нет. Более того, вещественное деление может выполняться быстрей целочисленного -- за счёт меньшей разрядности делимого и делителя. Вот в древних машинах, имеющих поддержку плавающей запятой, скорость выполнения этих операций могла быть существенно меньше, чем скорость выполнения целочисленных -- но там всё упиралось в количество транзисторов, не позволяющее сделать отдельное вещественное АЛУ и прочую поддерживающую его логику.

[jcxz]

однако и производительность 80486 при одинаковой тактовой частоте будет существенно выше, чем большинства ARMов (кроме разве что Cortex-A, и то вопрос дискуссионный). прочую поддерживающую его логику.

Весьма спорное утверждение. Уверен что в реальных задачах дело обстоит как раз наоборот.
Вот Вы тут на инкремент переменной в памяти ссылаетесь. У Вас программа вся из таких инкрементов состоит?
Как правило - таких операций очень мало (если компилятор нормальный и оптимизирует код).
А ну-ка - рассмотрите операцию например: a = b << 9 | c;
Сколько будет у ARM и сколько у x86
И учтите что у ARM регистров куда как больше чем было у 80486 и большинство переменных при оптимизирующем
компиляторе, находится в регистрах.
И это уже не говоря о том что на 80486 ещё было мало однотактных команд, а на ARM они почти все однотактные.
И это не говоря о том что современные ARM-контроллеры как правило имеют довольно большой объём внутренней
памяти с доступом на частоте ядра, в то время как в 80486 - всего-лишь небольшой L1-кеш.
И в 80486 нет никакого условного выполнения (как в ARM/Cortex), а только вермишель из условных переходов.
И т.п. Можно долго породолжать.

Код похоже очень интенсивно использует кучу(HEAP). А вот как интенсивно - под вопросом. Но на каком-то сайте сегодня вычитал, что поболее чем MP3 т.к. статических данных меньше. Выходит, что надо RAM>20KB.

Вы же сами написали: Total RW Size (RW Data + ZI Data) 7192 ( 7.02kB)
Куча, если используется, то находится где-то внутри этого объёма.
И использует-ли вообще???
Сам по себе никакой кодек не требует динамической памяти.
Её требует только некомпетентность разработчика. имхо

[KnightIgor]

Вы же сами написали: Total RW Size (RW Data + ZI Data) 7192 ( 7.02kB)
Куча, если используется, то находится где-то внутри этого объёма.
И использует-ли вообще???

Не совсем верно. Проект компилируется в библиотеку, без start up файла, поэтому в упомянутом объеме памяти HEAP не "учтен". Сколько же его надо на самом деле, не описано.

Коррекия - это я чушь написал. Видать, коллега собрал пример. А вот сколько кучи лежит внутри RW, зависит от настройки start up, но никак не от требований кодека.

Кстати, когда при компиляции ругня была по поводу неизвестной функции alloca, из-за чего пришлось включить заголовок alloca.h (это один из FUCK в коде ), я прочитал, что alloca размещает не в куче, а в стеке. Я сильно код не "сканировал", но думаю, что alloca используется для размещения локальной переменной функции без задействования опции --C99: C99 позволяет объявлять локальные переменные с динамической длиной; реализация под KEIL, к моему сожалению, выливается в вызов к malloc. Кстати, буду благодарен, если кто скажет, как убедить ARMCC размещать такое в стеке.

По поводу производительности процессора я присоединяюсь к поклонникам Cortex: сам (в качестве эксперимента) делал MP3 плейер с Helix декодером на SAM3U на 96MHz. Справляется спокойно. Если же формально посмотреть на vorbis, то там ассемблерная вставка для ARM7 предлагается, то есть, они пробовали на таком ARM. На круг Cortex будет пошустрее, так что можно предположить, что если уж не EFM32 на 48MHz, то STM32F4хх на >=120MHz или даже STM32F10x на 72MHz раскодирует.

Тогда буду использовать 2 кодека в связке: speex для речи(я ужал до 16KB flash/5K RAM в Wideband) + ADPCM под звуки.

Причёсанным speex с кратким пояснением, что там вызывать, не поделитесь?

Сообщение отредактировал KnightIgor - Dec 13 2014, 11:41