Попробовал впихнуть данный декодер (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 бит правый в младшем?

Да. 16 бит на канал. I2S и DMA пересылают тоже 16-битные слова.

Дело в том, что, насколько я понял, FIFO I2S у LPC17xx 32 битное, и не может работать с 16 битными данными напрямую.

То есть, чтобы выводить на ЦАП 16+16 бит стерео сигнал, нужно в FIFO записывать 32 битные слова с предварительно перемешанными каналами.

Или не так?

FIFO 8 32-разрядных слов. Но не обязательно писать все 32 бита, ИМХО. Выставляете размер данных 16 бит, стерео режим и все. При отправке каждого сэмпла из FIFO будет вычитываться одно значение.

Хм, вот содержимое ФИФО для разных режимов:
Нажмите для просмотра прикрепленного файла
То есть, если задать размер данных в 16 бит, то, как видно, одна 32 битная ячейка ФИФО будет содержать два 16 битных сэмпла.
Но никак не один сэмпл.

Что-то я Вас немного не пойму

Вот меня и смущает такая организация ФИФО - как бы не пришлось делать лишнюю работу по склеиванию ручками двух сэмплов (16 бит) в один (32 бита)

ЗЫ: в принципе, в случае, если выход декодера в памяти выглядит как чередующиеся 16 битные полуслова, проблемы нет - DMA будет копировать сразу 32 битное слово (два сэмпла) в каждую ячейку ФИФО.

Единственное, могут попутаться местами каналы, но DAC23 имеет специальную для этого фичу, кажется

Хм. Вы мне глаза открыли. Значит у меня в проекте ошибка. Интересно, как же оно работало. Надо будет разобраться.

А декодер действительно выдает "смешанный" поток.

Смонтировал на отладочной платке ЦАП TLV320DAC23, рядом работает ЖКИ дисплей по 8 битной параллельной шине.
ЦАП висит на I2C вместе с AT24C01B на проводах длиной около 20 см.

Так вот, если с EEPROM проблем никаких нет, то DAC23 меня уже запарил ошибками на I2C - то NACK сразу после выдачи адреса даёт, то NACK после записи одного байта, а то вообще шину подвесит.

Происходит это только если одновременно во время передачи по I2C в ЦАП идёт запись в ЖКИ.
Причём, если отвести провода I2C от проводов ЖКИ - ошибок становится много меньше...

Что за проблемы у этого цапа? Какой-то корявый у него интерфейс, слишком уж чувствительный к наводкам\пульсациям.

По осциллографу ничего критичного не видно, епромка пашет как часы, а эта какашка запарила уже

У кого есть опыт с DAC23\AIC23 - ничего подобного не наблюдали?

В linux работает отлично

Попробуйте уменьшить сопротивления подтяжек и поставьте их ближе к кодеку. Либо вообще на SPI перевесьте.

Поставил резисторы подтяжек вплотную к ЦАПу - стало ещё хуже, кол-во ошибок увеличилось.

Сейчас стоят резисторы 3к3, ставил и 1к5 - без результата.

Вероятно, всё дело в разводке, не разделены земли ЖКИ и ЦАПа.

Почему 3к3?

А сколько нужно?
Номиналы пуллапов зависят от суммарной ёмкости линий и частоты.
Частота интерфейса 400 кГц, чем меньше подтягивающие резисторы - тем круче фронты - тем выше достигаемая скорость передачи.

Плюс, по спецификации на ЦАП rise time не должен превышать 300 наносекунд.
По осциллографу видно, что это время значительно больше.

Поэтому, имхо, чем меньше пуллапы - тем лучше.

Подключение к ЦАПу отдельной земли не дало никакого результата.
Вроде решил проблему с DAC23 установкой на пины I2C микросхемы керамики по 150 пикофарад.
Дурдом, конечно, но вероятно причиной сбоев являлись наведённые с параллельной шины ЖКИ помехи, которые давали ложные срабатывания логики интерфейса внутри ЦАПа.

Причём епромка оказалась к этим наводкам совершенно нечувствительной, что делает ей честь.

В ЦАПе предусмотрен фильтр коротких импульсов в 50 нс, который оказался совсем неэффективным.
Если переключить щупы осциллографа на входной делитель х10, то на сигналах становятся видна модуляция логических уровней, с частотой в несколько мегагерц и амплитудой до 500 милливольт (если верить китайскому осциллографу ).
Очевидно, что ЦАП принимает эти помехи за полезный сигнал.

Неужели величина в 500 милливольт достаточна для уровня логической 1 для I2C?
Да и могут ли электромагнитные наводки достигать таких величин, интерфейс-то вроде не высокоомный?

Теперь придётся разводить сигналы I2C на платах аккуратнее, вдали от быстрых сигнальных проводников или под надёжным прикрытием замляных полигонов.

Почитаешь форумы, так народ тянет провода на метры и проблем вроде нет.
А тут всего 20 см и уже не хорошо

Хм. Странно. 500 мВ при статических уровнях влиять не должны. А если наложить эту наводку на фронт?

Наводка видна только на 3.3в или 0в, а фронты чистые.

Опять же, с подключенными щупами осциллографа х1 (без делителя) - модуляция очень незначительная, но ЦАП продолжал глючить.

Ещё не подавал звуковой сигнал по I2S, надеюсь, эти выводы будут не так восприимчивы к помехам.

если уж пошла такая пьянка на счет I2C то вот что скажу: надо было выставлять байт на экспандере портов PCA9555, причем на максимальной частоте 400КГц. В итоге I2C заработал без ошибок только при пуллапах 750 Ом. При этом фронты стали выглядеть более прямоугольными в отличие от 5.1кОм кот были в начале пути. Длина линиий SDA SCK между контроллером и экспандером было около 5 см. Вот такие пироги.