Кодек 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 сыплется. А вникнуть во все ребусы - знаний пока маловато.

Спасибо.

Я заинтересовался, скачал и сунул код в KEIL. Повылазило много чего. Почти дочистил.
Но у меня нет слов, одни матюки. Это во всем "open source" такой грязный код?!

Например, return (-1);, хотя функция объявлена как uint32_t. Ладно, идет предупреждение. Почему бы не написать return (~0);?
Кто тут в GCC компилирует? Это что, если void *ptr объявлена, то потом можно безнаказано написать ptr += BLABLA, и ничего за это не будет?!

Я просто фигею....

П.С. Короче, приложил проект, который компилируется. Без ассемблерных вставок: полагаемся на компилятор. Что изменил, ищите по тексту слова FUCK и IDIOT.

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

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

другими словами вы не знаете разницы между CISC и RISC?


на платах дискавери регулярно делают mp3 плееры и прочую мультимидийную фигню. Не знаю как там с битностью звука и потока, но в целом думаю что-то из кортексов подобрать можно.

Спасибо за помощь.
Попытался собрать под первый попавшийся таргет(32F100, -O2). Выходит такой футпринт:

Печалька.
Весьма толстый камень по моим меркам требуется и это только декодер сам в себе. Под простые девайсы вроде говорящих часов не подходит. Код похоже очень интенсивно использует кучу(HEAP). А вот как интенсивно - под вопросом. Но на каком-то сайте сегодня вычитал, что поболее чем MP3 т.к. статических данных меньше. Выходит, что надо RAM>20KB.
Тогда буду использовать 2 кодека в связке: speex для речи(я ужал до 16KB flash/5K RAM в Wideband) + ADPCM под звуки.

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


Вы же сами написали: 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 раскодирует.


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

Вот для Speex.
Узкополосный режим:

Ширикополосный режим(звук сочнее и приятней):

В RO data уже включена звуковая демка длиной 16 секунд.
Это собрано под отладку VL discovery(32F100, 24МГц). На PA4 через кондёр пару мкф вешаем наушник и слушаем речь ))
Но буфер у ЦАПа не очень мощный, поэтому лучше добавить где-то 100 Ом, так меньше искажений.
В main.h - настройки декодера:
SND_8KHz, SND_16KHz - режим 8/16К
ENCODED_FRAME_SIZE - скорость потока под выбранное качество.
play_message() - принимает указатель на звуковой массив и играет его. Здесь вроде не так запутанно как в Vorbis.
Декодер требует кучу не меньше 5,5 кбайт.
Ну собственно это проект по мотивам аппноута ST(диктофон), его один человек перетащил на VLdiscovery, я вырезал лишние режимы для экономии памяти.
PCM WAV кодируются в заголовки с помощью утилиты от Energy Micro(тоже есть аппноут).

Проект брать здесь:
https://yadi.sk/d/_8sxQCQhdM9C2

Попался проект декодера OGG под какую-то плату на STM32F103ZE:
https://github.com/zootboy/micro/tree/maste...les/5_media_ogg
http://code.google.com/p/stm32radio/
Судя по декларации буферов потребует десятки КБ ОЗУ.

Коль вы занимались Speex и с ним мало мальски разобрались, и судя по инфе первоисточника Speex он содержит следующие фичи:
Narrowband (8 kHz), wideband (16 kHz), and ultra-wideband (32 kHz) compression in the same bitstream
Intensity stereo encoding
Packet loss concealment
Variable bitrate operation (VBR)
Voice Activity Detection (VAD)
Discontinuous Transmission (DTX)
Fixed-point port
Acoustic echo canceller (AEC)
Noise suppression (NS)

Посему вопросы:
1) Можно ли использовать отдельно VAD, NS, AEC без кодирования сжатия в CELP, а использовать только как эхоподовитель для телефонной линии?
2) И из сходя из первого вопроса - Что для этого надо подправить в коде, если кто то разбирался в структуре кода, может кто то решал подобную задачу?
3) Можно ли подключить внешний звуковой кодек по I2S и что для этого потребуется изменить в коде?

Заранее спасибо.

Портировал декодер MP3 га SAM7X
http://otladka.com.ua/index.php?page=shop....t&Itemid=71

В документации было написано, что достаточно 20-22MIPS.

Сам не мерял, stereo 128kbit работало,256 не всегда.
По моему страница программы была на ассемблере.

Я когдато сильно интересовался декодерами МП3. Помню что минимальные результаты были у людей на процах 60-70 Мегагерц с загрузкой 50%.
128 бит. Но по моему это был не кортекс. Гдето так.

Я когда-то давно этим занимался и даже есть проект....я его сейчас откомпилировал в кейл 4.73 ...процессор NXP LPC1788
У меня здесь портированный код,взятый с указанного вами сайта.Все дефайны приведены к кейловским,файл 1.с-это просто массив с данными тестового ogg-файла...для целевой платы нужно дополнительное SDRAM ОЗУ,так как при портировании кода наткнулся на код ogg_realloc(1024*1024). Переменная val в файле main.c- это собственно говоря и есть аудиоданные декодированного файла...

Рекомендую сделать следущее- взять сгенерировать синус 1кГц с помощью какого-либо звукового редактора,например "аудосити" или "саунд форж" сохранить этот синус в формате ogg и обозвать файл как 1.ogg
далее при помощи кейловской утилиты FCARM (keil\bin\fcarm.exe 1.ogg) получить файл 1.с удалить ненужное,оставить только объявление массива
вставить этот файл в проект заместо имеющегося,откомпилировать
активировать Logic Analizer в симуляторе,добавить в него переменную val и запустив на исполнение,теоретически можем наблюдать что-то похожее на синус 1кГц в этом самом Logic analizer-e

Кстати,рекомендую обратить внимание на микросхему VS1063 от VLSI...дешевле обойдется

https://cloud.mail.ru/public/6PwH/uHneda3ZY собственно сам проект

486 DX 100 MHz нормально играл mp3 в WinAMP под Win95, что вы тут лечите?