mp3 acc wma декодеры под cortex-m3 Опции

[Dron_Gus]

Начал мучить железяку на LPC1768. Захотелось мне сделать плеер. Чтобы с периферией разобраться да и производительность оценить. Столкнулся с тем, что все основные декодеры того же mp3 имеют достаточно объемные вставки на асме. Все что нашел имеют порты пока что только под ARM7 (ARMv4) в режиме ARM. Естественно оно не собирается под ARMv7. Кто-нить знает, какой открытый проект уже портанулл свое произведение на Cortex?

[Doka]

а какая производительность декодирования у вас получается без портирования asm в thumb2, используя функциональные си-заглушки?

[Dron_Gus]

Написать бы эти заглушки. Я не настолько силен в алгоритмах и/или армовском ассемблере, чтобы их написать.

[Doka]

я так полагаю что под "основные декодеры того же mp3" понимается как - минимум libMAD - для РС-реализации разве в нём нету этих си-функций?

[Dron_Gus]

Спасибо. Что-то я не подумал.
Пока нашел real-network'вский декодер, у него всего пара инлайн-функций. Они нормально компилятся и под cortex.

А вообще я нашел следующие декодеры: libmad, mpg123, ffmpeg, RealNetworks'овский.

[Doka]

так вроде у RealNetworkово тоже всё складненько:

Код

* polyphase.c - final stage of subband transform (polyphase synthesis filter)
* Look in the appropriate subdirectories for optimized asm implementations
*   (e.g. arm/asmpoly.s)

там же тоже можно собрать консольное Win32 приложение изпод ВижалСтудио

В любом случае, результат мне тоже интересен

[AHTOXA]

В любом случае, результат мне тоже интересен

+1. Ждём отчёта

[sadat]

Есть на stm32 проектик, может, поможет....
http://www.stm32circle.com/projects/project.php?id=82

[Dron_Gus]

Спасибо!

Не хотят они меня регистрировать. А иначе файл не скачать. Он у Вас есть. На мыло не вышлете? dron_gusсобакамэилру

[AHTOXA]

файл не скачать

Нажмите на ссылку правой мышой и выберите "сохранить как" :-)

[Dron_Gus]

спасибо!

Однако. Давно я такой защиты не встречал.

[sonycman]

Есть на stm32 проектик, может, поможет....
http://www.stm32circle.com/projects/project.php?id=82

Написано, что есть проблемы с битрейтом 320 kbps.
Чёрт, STMка не справляется.
Может, у LPC получится без "заиканий"?

[defunct]

Нажмите на ссылку правой мышой и выберите "сохранить как" :-)

Чёй-то оно не того. сохраняет download.htm если так сделать. браузер - IE-7.
или уже прикрыли лавочку..
Может кто-нить зальет на ftp?

[Dron_Gus]

Написано, что есть проблемы с битрейтом 320 kbps.
Чёрт, STMка не справляется.
Может, у LPC получится без "заиканий"?

Странно это. SAM7 справлялся с 320 кбит. А тут и попугаев больше и частота выше. Мне все никак не победить CrossStudio и не проверить толком.

Может кто-нить зальет на ftp?

Залил /upload/MCs/ARM/stm32/mp3/

[sonycman]

Странно это. SAM7 справлялся с 320 кбит. А тут и попугаев больше и частота выше. Мне все никак не победить CrossStudio и не проверить толком.

Значит, оптимизация кода плохая.

Вообще удивляет стремление людей во всякую мало мальскую поделку всовывать OS.
Чтобы потом возиться с её проблемами...

[defunct]

Залил

спасибо

[VslavX]

Значит, оптимизация кода плохая.

Гм, похоже, что Cortex-M3 не имеет нормального аппаратного умножения - 32x32 возвращает только младший 32-битный огрызок. В MP3 самая ресурсоемкая часть - это выходное преобразование, а там умножений - "мама не горюй", и сейчас специально посмотрел - MAD старшими битами результата пользуется, также "в работе" умножение с накоплением. Поэтому добиться скорости сравнимой с ARM7 будет сложновато, ИМХО. Или я ошибаюсь и нормальное умножение есть и я его просто не нашел?

[Dron_Gus]

Судя по этому http://infocenter.arm.com/help/topic/com.a...QRC0001_UAL.pdf есть.
И по этому http://infocenter.arm.com/help/index.jsp?t...e/Chdbhfja.html .

Код

Multiply with 64-bit result    32    UMULL, SMULL, UMLAL, and SMLAL.
unsigned accumulate long UMLAL{S} RdLo, RdHi, Rm, Rs N Z C* V* RdHi,RdLo := unsigned(RdHi,RdLo + Rm * Rs)

Но это Thumb-2. CrossWork 1.* такой не умеет генерить.

[VslavX]

Код

Multiply with 64-bit result    32    UMULL, SMULL, UMLAL, and SMLAL.
unsigned accumulate long UMLAL{S} RdLo, RdHi, Rm, Rs N Z C* V* RdHi,RdLo := unsigned(RdHi,RdLo + Rm * Rs)

Но это Thumb-2. CrossWork 1.* такой не умеет генерить.

О, спасибо, а то я чего-то сразу в описании ARMv7 этого не нашел. Помню, что в обычном thumb-е нормального умножения не было, и расстроился что и на Cortex будет грустно, но как оказалось - все OK.

[sonycman]

А вообще какой смысл делать декодер силами контроллера?
Того же кортекса, к примеру?

Всё равно все ставят внешний чип - ЦАП?
В чём экономия по сравнению с внешним декодером?

А если воспользоваться родными ЦАПами кортекса?

Но всё равно было бы интересно запустить рабочий софтовый декодер. Правда, только если он ничем не будет уступать тому же VS1011 в плане поддержки битрейтов и качества звука...

ЗЫ: эх, вот если бы контроллеры класса кортексов имели на борту хоть какой нибудь DSP

[blackfin]

ЗЫ: эх, вот если бы контроллеры класса кортексов имели на борту хоть какой нибудь DSP

"Какой-нибудь DSP": bf527c..

[Dron_Gus]

А вообще какой смысл делать декодер силами контроллера?
Того же кортекса, к примеру?

Всё равно все ставят внешний чип - ЦАП?
В чём экономия по сравнению с внешним декодером?

А если воспользоваться родными ЦАПами кортекса?

Но всё равно было бы интересно запустить рабочий софтовый декодер. Правда, только если он ничем не будет уступать тому же VS1011 в плане поддержки битрейтов и качества звука...

Много вопросов.

Свою цель я обозначил в начале топика. В сравнении с готовыми декодерами - большая гибкость и апгрейдо-пригодность. Я, например, хочу добавить flac. ЦАПы у этого Cortex'а, боюсь, отдыхают в сравнении с тем же tlv320aic23

[sonycman]

"Какой-нибудь DSP": bf527c..

Ага, в 289 mini-BGA. Нафиг, нафиг

Свою цель я обозначил в начале топика.

Ну и как, есть какие нибудь успехи в портировании софта?

[Dron_Gus]

Угу. Декодеры AAC и MP3 cобираются без проблем. ФС работает. Но вот при декодировании и того и того вылет в HardFault. Грешу на инициализацию дополнительных блоков памяти.

[sonycman]

Угу. Декодеры AAC и MP3 cобираются без проблем. ФС работает. Но вот при декодировании и того и того вылет в HardFault. Грешу на инициализацию дополнительных блоков памяти.

А декодер взяли от проекта на основе STM32?

[Dron_Gus]

И да и нет. Декодер там RealNetworks'овский. Его еще немцы в своем плеере на sam7 использовали. Обертку я взял от немцев - удобная она.

[sonycman]

И да и нет. Декодер там RealNetworks'овский. Его еще немцы в своем плеере на sam7 использовали. Обертку я взял от немцев - удобная она.

Ну а вставки в Thumb2 присутствуют?

[Dron_Gus]

Присутствуют, но не компилятся, кажется. Проект дома. Не помню уже. Кажется я заменил большуший исходник на асме аналогом на Си.

[Dron_Gus]

Посмотрел. Компилятся. Надо бы проверить как они компилятся.

[sonycman]

То есть нормальных вставок в родном THUMB2 не получилось найти, или руки пока не дошли собрать?

Тоже интересно, что получится в результате.

А ось в проекте не присутствует случайно, как у немцев?

[Dron_Gus]

То есть нормальных вставок в родном THUMB2 не получилось найти, или руки пока не дошли собрать?

Тоже интересно, что получится в результате.

А ось в проекте не присутствует случайно, как у немцев?

Вставки заменены сишными аналогами. Но самая ресурсоемкая процедура как раз в thimb2 - asmpoly_thumb2.s, взята из проекта от stm32. Вот ее надо проверить. Т.к. CS 1.7 вроде как не умеет thumb-2 и что там в итоге выходит - х.з., может он arm код генерирует.

Я пока не могу уделять этому занятию много времени, поэтому не знаю, когда будут результаты. Всем желающим могу отдать проект в его текущем состоянии (нерабочем ).

Про ось запутался, про какой проект вы говорите. У stm'шников какая-то CircleOS. У немцев с sam7 (http://embdev.net/articles/ARM_MP3/AAC_Player) оси нет. Я вначале прикрутил freertos, потом открутил нафиг.

З.Ы. а для CrossStudio 2.* клизмы еще нет?

[zksystem]

Свою цель я обозначил в начале топика. В сравнении с готовыми декодерами - большая гибкость и апгрейдо-пригодность. Я, например, хочу добавить flac. ЦАПы у этого Cortex'а, боюсь, отдыхают в сравнении с тем же tlv320aic23

Посмотрите на VS1053B:

Decodes multiple formats
Ogg Vorbis
MP3 = MPEG 1 & 2 audio layer III (CBR+VBR+ABR)
MP1 & MP2 = MPEG 1 & 2 audio layers I & II optional
MPEG4 / 2 AAC-LC(+PNS), HE-AAC v2 (Level 3) (SBR + PS)
WMA4.0/4.1/7/8/9 all profiles (5-384 kbps)
FLAC lossless audio with software plugin (upto 24 bits, 48 kHz)
WAV (PCM + IMA ADPCM)
General MIDI 1 / SP-MIDI format 0

Encodes three different formats from mic/line in mono or stereo
Ogg Vorbis with software plugin
IMA ADPCM
16-bit PCM

[sonycman]

Пока сделал декодер на чипе VLSI, но потом хочется собрать софтовый декодер.

Какие ЦАПы посоветуете использовать, кроме tlv320aic23?
Требования к качеству звука не шибко высокие, тем более, раз речь идёт об mp3.

Нет ли в природе буферизованных ЦАПов или кодеков, которые бы сами генерировали нужную частоту сэмплирования?

И что-то я не особо впечатлён возможностями генератора клока для I2S в STM32 (кроме новых чипов с отдельным PLL).
Тупой целочисленный делитель, необходимо подгонять кварц для более менее точного Fs.
Не сравнить с дробным делителем LPC17хх

[Dron_Gus]

По второму вопросу tlv320aic23 умеет быть мастером. Думаю, Вы в курсе Самый популярный вариант. Все остальные, которые знаю, клок генерировать не умеют.

Про I2C у STM'ов, а Вы их SPI пробовали? Тоже то еще. Видно захотели сильно универсальный модуль сделать да не вышло SPI master/SPI slave/I2S/и еще что-то однопроводное.

[sonycman]

По второму вопросу tlv320aic23 умеет быть мастером. Думаю, Вы в курсе Самый популярный вариант. Все остальные, которые знаю, клок генерировать не умеют.

Про I2C у STM'ов, а Вы их SPI пробовали? Тоже то еще. Видно захотели сильно универсальный модуль сделать да не вышло SPI master/SPI slave/I2S/и еще что-то однопроводное.

Думаю поработать с tlv320dac23, он без ненужного мне АЦП, но мастером быть тоже умеет (есть у TI и более простые ЦАПы с таким режимом).

Но что-то особой пользы от мастера я не увидел. Внешний-то клок - MCLK - всё равно надо подавать снаружи, и подавать разный для разных частот сэмплирования (например, для Fs = 44.1 кГц- 11.289 МГц, а для Fs = 48 кГц - уже 12.288 МГц).
Имхо, проще будет сразу все частоты формировать контроллером...

К SPI у меня претензий нет. Ну, кроме такого же "тупого" делителя (2^x) для SCLK. Но это и у конкурентов так.

А вот I2C у STM отвратительный. Громоздкий, да ещё и еррата кусается...

[Dron_Gus]

Но что-то особой пользы от мастера я не увидел. Внешний-то клок - MCLK - всё равно надо подавать снаружи, и подавать разный для разных частот сэмплирования (например, для Fs = 44.1 кГц- 11.289 МГц, а для Fs = 48 кГц - уже 12.288 МГц).
Имхо, проще будет сразу все частоты формировать контроллером...

К SPI у меня претензий нет. Ну, кроме такого же "тупого" делителя (2^x) для SCLK. Но это и у конкурентов так.

А вот I2C у STM отвратительный. Громоздкий, да ещё и еррата кусается...

А погрешности при 12 МГц кварце (usb mode) не устраивают?

SPI мне не понравился тем, что не умеет дергать CS (SS) после каждого байта. Да и после окончания передачи блока не дергает. Короче, как на sam7 приходится дергать руками.

На I2C я вообще забил. Проще ногами дергать, чем адекватно управлять их модулем.

[adnega]

Хм..
По I2C подключил дисплей TIC-154, на SPI SD/MMC-карта (правда, CS ручками дергаю), делал и развертку VGA-сигнала (640x480) через SPI на stm32f103t4 - из-за недостатка памяти только текстовый режим (а ля, просмотр отладочных сообщение через RS232/TTL).
Во всех реализациях проблем не имел - хотелось бы узнать какие есть проблемы (страшно ведь...)?

[Dron_Gus]

Хм..
По I2C подключил дисплей TIC-154, на SPI SD/MMC-карта (правда, CS ручками дергаю), делал и развертку VGA-сигнала (640x480) через SPI на stm32f103t4 - из-за недостатка памяти только текстовый режим (а ля, просмотр отладочных сообщение через RS232/TTL).
Во всех реализациях проблем не имел - хотелось бы узнать какие есть проблемы (страшно ведь...)?

Читайте еррату и апноты. По I2C нельзя послать 1 байт. Достатоно криво реализуется обработка исключительных ситуаций. У меня устройство с возможностью горячего подключения/отключения, так что для меня было критично.
По СПИ, кроме перечисленного, только 8/16 бит. ИМХО неудобно иногда.

З.Ы. раз у Вас все работает, переживать не стоит.
З.З.Ы. мне все же привычней реализации этих модулей от Atmel & NXP.

[sonycman]

По I2C нельзя послать 1 байт.

Можно всё, по крайней мере на medium density девайсах.
Просто для 100% надёжности необходима реализация I2C через прерывания или DMA.

Я пока не могу уделять этому занятию много времени, поэтому не знаю, когда будут результаты. Всем желающим могу отдать проект в его текущем состоянии (нерабочем ).

Ну а как прогресс с софтовым декодером? Есть результаты?

[Dron_Gus]

Ну а как прогресс с софтовым декодером? Есть результаты?

Нет пока. Меня в командировку на севера на НГ хотят отправить, не до того.

[sergvks]

Декодер там RealNetworks'овский. Его еще немцы в своем плеере на sam7 использовали.

Собирал этот декодер в кейле, для нормального декодирования на stm32 больших битрейтов приходилось разгонять проц до 96МГц ибо у STM32 дюже флеш тормознутый.

[sonycman]

Собирал этот декодер в кейле, для нормального декодирования на stm32 больших битрейтов приходилось разгонять проц до 96МГц ибо у STM32 дюже флеш тормознутый.

Больших битрейтов - это каких?
А в декодере вставки на асме есть?
Наиболее юзабельные функции располагать в RAM пробовали?

Просто, после сообщений о том, что даже на тормозном SAM7S 320 kbps не лагает - слышать о проблемах на STM странновато...

[sergvks]

После кое-какой правки исходников я пришёл к тому, что находится во вложении.

Прикрепленные файлы

 mp3.zip ( 72.52 килобайт ) Кол-во скачиваний: 198

 

[sonycman]

Спасибо!
Разбираться буду, когда начну след. проект, уже на LPC1768

[Dron_Gus]

Добил. Декодирование mp3 @ 256 на lpc1768 @ 100 MHz - 74..78%. CrossStudio 1.7, без оптимизации, thumb. Данные грузятся с sd-карты результат выпихивается через dma на tlv320.

Оптимизация O3 - mp3 @ 320 на lpc1768 @ 100 MHz - 28..30%. Либо я что-то не правильно мерю. Но underun'ов точно нет. Приведу проект в порядок - выложу.

Всех с наступившим Новым Годом. Пусть у всех в Новом Году будет хватать времени заниматься хобби.

[sonycman]

Добил. Декодирование mp3 @ 256 на lpc1768 @ 100 MHz - 74..78%. CrossStudio 1.7, без оптимизации, thumb. Данные грузятся с sd-карты результат выпихивается через dma на tlv320.

Оптимизация O3 - mp3 @ 320 на lpc1768 @ 100 MHz - 28..30%. Либо я что-то не правильно мерю. Но underun'ов точно нет. Приведу проект в порядок - выложу.

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

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

Пусть у всех в Новом Году будет хватать времени заниматься хобби.

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

[Dron_Gus]

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

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

Код

void decode_start(void)
{
   d_start = RIT->RICOUNTER;
}

void decode_end(void)
{
   d_tot += RIT->RICOUNTER - d_start;
}

void play_start(void)
{
   //reset tottal decode time counter
   d_tot = 0;
   //reset
   RIT->RICOUNTER = 0;
   //start
   RIT->RICTRL = (1 << 0) |  //clear int flag
                 (0 << 1) |  //don't clear timer on equal
                 (1 << 2) |  //debug mode - halted on cpu halt
                 (1 << 3) |  //enable
                 (0);
}

void play_stop(void)
{
   unsigned int tot;
   //
   tot = RIT->RICOUNTER;
   //
   RIT->RICTRL &= ~(1 << 3); //stop counter
   //
   printf("Total ticks  = %d\r\n", tot);
   printf("Decode ticks = %d\r\n", d_tot);
   printf("Average load = %d %%\r\n", ((long long)d_tot * 100) / (long long)tot);
}

и

Код

    decode_start();
     err = MP3Decode(hMP3Decoder, &read_ptr, &bytes_left, dac_buffer[writeable_buffer], 0);
     decode_end();

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

[sonycman]

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

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

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

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

[Dron_Gus]

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

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

[Dron_Gus]

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

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

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

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

Прикрепленные файлы

 Player_.rar ( 911.33 килобайт ) Кол-во скачиваний: 399

 

[OVladimir]

После кое-какой правки исходников я пришёл к тому, что находится во вложении.

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

[goodwin]

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

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

[zksystem]

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

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

[OVladimir]

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

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

[zksystem]

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

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

[OVladimir]

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

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

[Axel]

...Может, посоветуете конкретный ADPCM декодер...

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

[sonycman]

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

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

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

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

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

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

Так ли это?

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

[Dron_Gus]

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

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

[sonycman]

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

Спасибо!

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

[Dron_Gus]

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

[sonycman]

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

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

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

Или не так?

[Dron_Gus]

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

[sonycman]

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

Хм, вот содержимое ФИФО для разных режимов:

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

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

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

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

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

[Dron_Gus]

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

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

[sonycman]

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

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

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

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

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

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

[sasamy]

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

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

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

[Dron_Gus]

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

[sonycman]

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

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

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

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

[skripach]

Сейчас стоят резисторы 3к3

Почему 3к3?

[sonycman]

Почему 3к3?

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

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

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

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

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

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

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

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

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

[Dron_Gus]

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

[sonycman]

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

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

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

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

[Halfback]

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