Интересные результаты
Имхо - без оптимизации не стоит компилировать вообще.

Не подскажете, какую методику можно использовать для замера занятости процессора?
Вот у вас - 70%... 30%... как это точно измерить?


И ещё бы не переводились деньги на любимое занятие.
Иногда это бывает весьма затратно

Я использовал Repetitive Interrupt Timer. Перед началом воспроизведения сбрасываю и запускаю. Перед каждым вызовом декодирования запоминаю текущее значение таймера, после выхода из декодирования считаю количество затраченных тактов. Всё это суммирую и в конце делю на текущее значение таймера. Да, собсно, что рассказывать:

и


Единственное, таймер лопатит на CCLK, поэтому болье 42 сек им считать нельзя.

Понятно, спасибо.

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

А чем вы прошиваете/дебажите 1768?

Тоже вот заказал отладку с ним, и вот думаю, не поменять ли устаревший МТ-Линк v5 на что-либо получше.

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

Я дебажу МТ-Линком. Вполне устраивает. На работе с stm32 работаю u-link'ом для кортексов. Никаких преимуществ не заметил. Разве что второй умеет работать по 2 проводам, но пока дефицита ног не ощущаю. Если отладка от отечественного производителя - то там точно полный j-tag разведен.

Выкладываю текущее состояние моей поделки.

Возникла непреодолимая проблема. Два кодека (mp3 и aac) не хотят компилироваться вместе. Ругаются на кучу redefine'ов. Может кто умный глянет? В текущем варианте включен mp3, чтобы добавить AAC надо глобально задефайнить ADD_AAC и включить в сборку ветку real-aac.

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

Разобрался. Объектники от разных декодеров пересекались именами.

Попробовал впихнуть данный декодер (RealNetworks) в свой STM32f103RB (RAM 20 KB), просто так не лезет, попробовал указать #define MAX_NCHAN 1 (для моей задачи подходит моно), всё влезло, но при декоде 6 фрейма вылетает в HardFault_Handler из PolyphaseMono(). Заметил, что как-то странно изменяется sbi->vindex. Вопрос, собственно, в следующем: Как заставить работать данный декодер с моно МП3?

Возникает резонный вопрос: А на кой ляд для МОНО MP3? Это явно не проигрыватель для прослушивания аудио. А для "рупора" хватит всяческих ADPCM.
Да и лицензионные ограничения не заботят...

Может человеку необходимо качество звука высокое и большое сжатие файлов.

Действительно, задача состоит в том, чтобы проигрывать голосовые сообщения, которые может записывать сам пользователь при помощи компъютера и нехитрых действий. Так же ограничена память для хранения голосовой информации (несколько мегабит флэш, никаких СД). Опыта в аудио кодеках у меня нет, поэтому, сразу подумал про МП3.
Может, посоветуете конкретный ADPCM декодер (заодно и кодер, хотя, это было бы лучше вынести в отдельную тему)?
И всё-таки хотелось бы прочитать ответ о моно МП3.

Если Вы собираетесь изготавливать коммерческое устройство, то за mp3 придется платить лицензию. Лично я, в своих подобных устройствах, а именно, транспортных автоинформаторах использовал внешний декодер mp3, такой как VS1001K фирмы vlsi. Флеш память сейчас очень подешевела, поэтому, имхо проще сделать ADPCM или какой-нибудь SPEEX или FLAC

С лицензией разберёмся, VS1001K ставить не хочется (дополнительные деньги и место на плате, которая, к слову сказать, уже спроектирована и собрана), хочется оставить всё как есть и впихнуть МП3 в 20 КБ посредством настройки декодера. Покачто мысль дошла только до того, чтобы уменьшить максимальное число каналов с 2 до 1, тогда всё помещается, но не работает. Отсюда и вопрос, стоит ли возиться с уменьшением требуемого кол-ва РАМ и вообще, реально ли это сделать и каким образом? В конце концов есть вариант поставить процессор из той же линейки с большим РАМ, но этого делать тоже не хочется пока, бо STM32F103RB и STM32F103R8 уже закуплены.

Их навалом в Инете... Я один такой прикрутил к проекту на LPC23, выход - через АЦП. Вроде ничего звучит. Памяти требует - 4kB на секунду звука, RAMa - совсем немного.

Глубоко пока в исходниках не копался, вот думаю - какие буферы в памяти для воспроизведения MP3 нужны?

Надумал вот что.
Нужны два сэмпловых буфера по 1152 сэмпла на канал - один для распаковки текущего фрейма декодером, второй - для вывода из него звука по DMA на ЦАП.

Какой ширины сэмплы формирует декодер в Вашем проекте?

Контроллер у меня будет LPC1768, его I2S не может работать с 24 битными словами.
Тут или 16 бит - но тогда в одном 32 битном слове должны быть сразу оба канала.
Или 32 бита на сэмпл для каждого канала.

Ну и один буфер для подгрузки текущего файла. Размер нужен такой, чтобы в него (желательно) помещался один фрейм целиком.
Для 320 килобит это приблизительно 1100 байт.

Так ли это?

Ну и пока что не смотрел, сколько ОЗУ хочет непосредственно декодер уже кроме упомянутых выше буферов?

Декодеры выделяют себе память динамически. Мне хватило 28 Кб и для aac и для mp3 (естественно поочередно. кажется, mp3 потребляет больше). Буферы для ЦАПа - 2 буфера по 2400 по 16 бит. Это для стерео. Буфер для чтения файла - 4 КБ.

З.Ы. контроллер, кстати, тот же.

Спасибо!

То есть декодер "выдаёт" сэмплы в 16 битах?
И I2S у Вас работает в 16 битном режиме, на входе 32 битные слова - 16 бит левый канал в старшем полуслове, и 16 бит правый в младшем?