RTL00 MP3 player

[pvvx]

Поигрался еще с Helix, 192 kbs не тянет, а так все тоже, RAM в притык на RTL8710. на сколько понял при хардварном i2s dac нужно будет меньше RAM на is2 буфер, не будет PWM_HACK96BIT а это i2s buf /4

Не на 4, а больше и один канал.
RAM всегда в притык, если не RTL8711AM. Чем больше буфера - тем лучше и расставлены на предел имеющейся RAM. RAM более 1 Мег - уже можно ограничивать. Во всяком случае хватает без ухищрений и урезаний других частей - не ESP8266...
И почему 192 kbs не тянет? Не смогли переделать установки кодека и выходного битрейта?
Я не делаю полностью готовых приложений. Тут только пример и он пашет с приведенными ссылками на web-радио. Считаю, что полный проект соберет тот, кому это надо. Да и других ссылок на другие битрейты web-радио у меня нет – не люблю радио… во первых выбора нет, да одна болтовня, а на счет качества - там и 4-х бит хватает - вечно у них накручены тембры и ограничение амплитуды...

 

[mikush]

RTL8711AM как по мне дороговато,

И почему 192 kbs не тянет? Не смогли переделать установки кодека и выходного битрейта?

я так понимаю Helix отжирает СPU и таск ридера медленно загоняет входной буфер. vTaskGetRunTimeStats не компилится из ардуино, чего то не хватает.
оффтоп
за цену RTL8711AM можно взять что то типа orange pi zero или подобное с openwrt. значит нужно выжимать 8710

 

[pvvx]

RTL8711AM как по мне дороговато,

я так понимаю Helix отжирает СPU и таск ридера медленно загоняет входной буфер. vTaskGetRunTimeStats не компилится из ардуино, чего то не хватает.
оффтоп
за цену RTL8711AM можно взять что то типа orange pi zero или подобное с openwrt. значит нужно выжимать 8710

8710 хватает сполна. Там надо ещё поиграться приоритетами задач. Я не оптимизил это дело.

И если более углубляться – у них и у вас источник CPM в 4-ре бита на 44 кГц, т.е. даже 10 кГц вывести на полную амплитуду не может. Далее его зажали MP3. Когда найдете источник записи более 4-х бит на дискрет в 44 кГц – отпишитесь

The audio contained in a CD-DA consists of two-channel signed 16-bitLinear PCM sampled at 44,100 Hz.
Звуковой CD - Разрядность — 16 бит (линейное квантование*)
Линейное квантование - PCM u-law/a-law (4-ре бита и мантиса... )

 

[mikush]

8710 хватает сполна

мне хватит, я как раз жду dac, будет пару лишних кб рама. но и сейчас удовлетворяет, паралельно работает web сервер, udp и декодирование до 192. весь функционал который я планировал.
Еще нужно проревювить может у меня где то затык, импользовал только код для вывода i2s. так что вполне вероятно , 320 с флешки играет на stm32f103 по идеи 8710 должен тянуть

 

[pvvx]

мне хватит, я как раз жду dac, будет пару лишних кб рама. но и сейчас удовлетворяет, паралельно работает web сервер, udp и декодирование до 192. весь функционал который я планировал.
Еще нужно проревювить может у меня где то затык, импользовал только код для вывода i2s. так что вполне вероятно , 320 с флешки играет на stm32f103 по идеи 8710 должен тянуть

То, что есть жрет 60% времени CPU без оптимизаций. Там вроде команда посмотреть загрузку есть - "ATST".

 

[mikush]

То, что есть жрет 60% времени CPU без оптимизаций. Там вроде команда посмотреть загрузку есть - "ATST".

Arduino. чистый пример
320 поток "sentinel.scenesat.com/scenesatmax", 8000 заикаться и в лог шлет FIFO: Buffer Underrun,что аж терминал сума сходит
VLC на большом брате с кешем в 1ms играет нормально, вроде поток в норме.

 

[pvvx]

Arduino. чистый пример
320 поток "sentinel.scenesat.com/scenesatmax", 8000 заикаться и в лог шлет FIFO: Buffer Underrun,что аж терминал сума сходит
VLC на большом брате с кешем в 1ms играет нормально, вроде поток в норме.

Ещё раз - в коде нет поддержки битрейтов больше, чем в тестовом примере.
И для меломанов:
"Запись реального реверберационного процесса без потери информации представляет огромные трудности. Например, для помещения объемом 1000 м3 число отражений через одну секунду после начала реверберационного процесса составляет 511287 отр/с. Это значит, что отраженные лучи будут прибывать с интервалом менее 2 мкс, вызывая соответствующие флуктуации в выходном сигнале микрофона. Естественно, что даже при временном интервале между отсчетами 5,2 мкс (как для DVD-Audio) эти флуктуации не смогут быть зарегистрированы.

Тщательные измерения показали также, что в этих отраженных сигналах происходят быстрые амплитудные и фазовые сдвиги и быстрые нерегулярные изменения частоты (частотный джиттер). Когда два или несколько микрофонов распределены в помещении, и при этом происходит многодорожечная запись, то эти сложные временные соотношения между сигналами с частотной модуляцией при бинауральном прослушивании создают сдвиги временной разницы.

Как оказалось, слух к этим бинауральным сдвигам (бинауральный джиттер) очень чувствителен, даже если они составляют доли микросекунд!

Частоты дискретизации, используемые в современных системах, оказываются недостаточными, чтобы «схватить» эти тонкие временные сдвиги, что приводит к неточной локализации в периферической зоне и потере ощущения окружения и ощущения глубины. Таким образом, анализ показывает, что музыка, исполняемая в помещении, создает сложный звуковой сигнал, который соответствует чрезвычайно тонким и сложным способностям слуховой системы к его анализу. Процесс записи звука должен иметь разрешающую способность, соответствующую как сигналу, так и возможностям слуховой системы."
А кодек MP3 сжимает звук за счет устранения этой информации в помойку из потока.
"sentinel.scenesat.com/scenesatmax" переадресует http://primitive.be/scenesatmax:8000 "LOL 404"

Я могу вам закодировать звук на осциллографе у которого 4 канала по 16 бит на 10 MHz и далее в 100 Mbit в MP3. Куда его потом? На каждой web-радиостанции есть поток 96 кбит/c - его вполне хватает для вывода ШИМ. По этому пример содержит битрейты от 48 до 96 кбит/c - больше не требуется для возможностей вывода на ШИМ выходы.

 

[mikush]

я с Вами соглашусь на счет качества, да и мои скудные познания в схемотехнике (дак , усилитель и их питание )все качество входного потока умножит на ноль, просто спортивный интерес.
на хеликсе mp3dec 22% bitrate 192000

2:18:45.986> CPU total run time is 34587
2:18:45.986> TaskName    DeltaRunTime    percentage
2:18:45.986> ARDUINO        0        <1%
2:18:45.986> IDLE        750        74%
2:18:45.986> TCP_IP        10        <1%
2:18:45.986> Tmr Svc        0        <1%
2:18:45.986> main_task        0        <1%
2:18:45.986> i2c        0        <1%
2:18:45.986> rtw_check        0        <1%
2:18:45.986> cmd_threa        0        <1%
2:18:45.986> rtw_TDMA_        0        <1%
2:18:45.986> rtw_littl        0        <1%
2:18:45.986> mp3dec        230        22%
2:18:45.986> rtw_inter        10        <1%
2:18:45.986> rtw_recv_        10        <1%
2:18:45.986> reader        10        <1%
2:18:45.986> ARDUINO        0        <1%
2:18:45.986> rtw_xmit_        0        <1%

 

[pvvx]

просто спортивный интерес.

А я собирал что есть всего в помощь kissste. Он решил взять декодек и что шло к ESP8266. Ну это и перевел на RTL не думая и не анализируя других вариантов - чисто для сравнения ESP8266 c RTL8710AF. Получилось, что ESP82xx на Tensilica's L106 стараниями Espressif безоговорочно сдулся.

на хеликсе mp3dec 22% bitrate 192000

Ну вот, а говорили, что 320 не потянет.
Можно ещё поработать с расположением критически скоростного кода и его стека в TCM область RAM. Даст ещё до десяток % выигрыша.
Соберите декодек и выложите детям – пусть играются. А то уже пишут всякие из PADI и предлагают “как разработчику” бесплатные образцы их продукции… Вот на кого бы это всё свалить?

 

[mikush]

Соберите декодек и выложите детям – пусть играются.

Ваш кодек, прекрасно работает, выложу уже пример под хардварный i2s дак, как только он до меня доберется из поднебесной

 

[pvvx]

Протестировал FFT128real32.zip - 32 bit real FFT 128 points + windowing + magnitude (IAR, Keil, gcc) из Embedded Signals на RTL00.
Window16to32b_real( x, Hamming128_16b, N); // perform windowing function
[N] тактов:
[128] 1012, [1024] 7732, [2048] 15412, [4096] 30772

FFT128Real_32b(y,x); // call FFT routine
[128] 9765

Стек в TCM, код в SRAM. Видно, то SRAM вставляет такты ожидания, как и описано в доке к RTL.
Сравнительная таблица дана в PDF на сайте...
Буду нечто похожее лепить под свою задачу - надо справиться с ADC 250ksps 24 bit и анализом 28 частот по ДПФ окнами по 0.03 сек... RTL8710 вроде вписывается...

 

[pvvx]

# ATST

CLK CPU         200000000 Hz
RAM heap        22960 bytes
RAM free        5792 bytes
TCM heap        408 bytes
TCM ps_monitor  764 bytes
RAM Heap Memory List:
[0]=0x0x100522ec, 0
[1]=0x0x10003010, 1984
[2]=0x0x10059820, 272
[3]=0x0x1006af18, 20704
TCM Free List:
prev 100524e0, chunk 1fff5454, size 408

CPU total run time is 285907
TaskName        DeltaRunTime    percentage
log_servi               0               <1%
tskmad          180             17%
IDLE            810             80%
Tmr Svc         0               <1%
TCP_IP          0               <1%
rtw_check               0               <1%
cmd_threa               0               <1%
rtw_TDMA_               0               <1%
log_uart                0               <1%
rtw_littl               0               <1%
rtw_inter               10              <1%
rtw_recv_               20              1%
tskreader               0               <1%
rtw_xmit_               0               <1%

[MEM] After do cmd, available heap 22960+408

tskmad 180 17%
RTL8711AM как свои 200 МГц... Обгоняем ESP-32S...
Да, Espressif уже бесплатно раздает ESP-32S - Бесплатные ESP32 dev kit
- налетай на утюг, требующий минимум 1A для запуска и имеющий раза в два менее памяти для приложений, чем RTL00...

 

[pvvx]

После первого прохода "чистки" SDK и расстановки приоритетов задач, MP3 пошел уверенно на 83 МГц CLK CPU.

CLK CPU         83333333 Hz
RAM heap        23336 bytes
TCM heap        27928 bytes

CPU total run time is 1988826
TaskName        DeltaRunTime    percentage
loguart         2905            <1%
IDLE            407926          20%
Tmr Svc         162             <1%
TCP_IP          11365           <1%
rtw_check       0               <1%
cmd_threa       3009            <1%
tskreader       9767            <1%
rtw_littl       5567            <1%
rtw_inter       4541            <1%
rtw_recv_       17173           <1%
tskmad          1447303         72%
rtw_TDMA_       0               <1%
rtw_xmit_       3               <1%

Task List:
==============================
Name      Status Priority HighWaterMark TaskNumber
loguart         R       4       218     2
IDLE            R       0       36      3
Tmr Svc         B       5       438     4
TCP_IP          B       9       637     5
rtw_TDMA_       B       7       219     12
rtw_xmit_       B       5       183     7
tskreader       B       8       130     54
rtw_littl       B       10      439     10
rtw_inter       B       6       209     8
rtw_recv_       B       5       891     6
tskmad          B       7       106     55
rtw_check       B       5       219     11
cmd_threa       B       6       221     9

Приближаемся к потреблению BLE при MP3 на ШИМ через 2 x i2s
ESP-32S-шники "нервно курят в сторонке"
При старте памяти:
RAM heap 120432 bytes
TCM heap 64768 bytes
Потом всё на буфера...
Скоро кину с обновлением SDK на git...
Какая-то версия, проверенная, что собирается, скинута. Далее SDK будет расходиться с оф. версией всё больше и больше... Версии на git будут "не стабильные", пока не допилю следующий этап, а их предполагается много Короче SDK "пошел под пресс". Сейчас уже всё собирается с одной lib_wlan.a либ (и пару *.obj в lib_platform_new.a - hal_crypto.o + hal_spi_flash_ram.o). На все функции в либе lib_wlan.a и т.д., ROM есть заголовки и описания всех полей данных...

 

[Neov]

Пытаюсь собрать своим сборщиком, ругается линковщик

c:/projects/rtl00mp3-master/tools/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: c:\projects\RTL00MP3-master\build\app.axf section `.bf_data' will not fit in region `BD_RAM'
c:/projects/rtl00mp3-master/tools/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region RAM overflowed with stack
c:/projects/rtl00mp3-master/tools/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region `BD_RAM' overflowed by 6884 bytes
c:/projects/rtl00mp3-master/tools/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: warning: section `.valid' type changed to PROGBITS

в чем может быть дело?

 

[pvvx]

Пытаюсь собрать своим сборщиком, ругается линковщик

c:/projects/rtl00mp3-master/tools/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: c:\projects\RTL00MP3-master\build\app.axf section `.bf_data' will not fit in region `BD_RAM'
c:/projects/rtl00mp3-master/tools/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region RAM overflowed with stack
c:/projects/rtl00mp3-master/tools/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region `BD_RAM' overflowed by 6884 bytes
c:/projects/rtl00mp3-master/tools/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: warning: section `.valid' type changed to PROGBITS

в чем может быть дело?

Файлы линковщика другие (*.ld), так-же есть переименование секций для сборки boot-loader-а... Без переименования секций за раз не собрать boot и приложение. gcc не умеет менять имя сегмента данных в си, а приписывать секции к каждой var = "стринг".... Проще создать отдельную группу и махнуть разом все имена сегментов -> RTL00MP3/sdkbuild.mk at master · pvvx/RTL00MP3 · GitHub
Мне, например, тоже не понятно, зачем было делать загрузку boot в центр кучи .rodata и .data переменных rom-bios? Но такая ROM и уже не переписать...По этому boot несет в себе данные для ROM-BIOS. Иначе кранты API в ROM. Дополнительный кавардак ещё для объединения (совместного использования) структур данных ROM и пользовательской Image. В стандартном SDK данные ROM дублируются, что уменьшает объем памяти и требует доп. действий для их обновления и связей... Народ категорически не хочет покупать RTL871xAM, а в RTL8710AF мало памяти на всё Приходиться выжимать каждый байтик. И это только начало В дальнейшем весь одноразовый стартапный код (инициализации) будет заниматься нужными вещами после отработки, а не сидеть в RAM, занимая место. Ущё, если будет время, урежется глупый текстовый интерфейс к WiFi драйверу, что даст ещё десятки кило с увеличением возможностей... Думаю, что вашему питону придется потрудиться, распутывая это всё

 

[Neov]

Не могли бы выложить лог сборки?

 

[pvvx]

Не могли бы выложить лог сборки?

Какой? (т.е. с какой опцией mingw32-make.exe ?)
без '-s' уже не лезет в сообщение.
C '-n' или '-p'? - он будет к гегобайту
Без опций:

 

[pvvx]

@Neov - нет там ничего в сборке сложного, кроме описанного - нового *.ld и замены секций у rtl_boot.c.
Было 2 группы файлов, стало три: SRC_C, DRAM_C, BOOT_C.

"section `.bf_data' will not fit in region `BD_RAM'" - вообще в map нет такой секции - `.bf_data'. Оно есть только в старом *.ld, от оф. SDK.

 

[Neov]

@pvvx , оказвается я собирал устаревшую v03.
Сейчас получше, но проверка ASSERT(__ram_image_end__ == 0x100020c0, "Error rom-bios-boot code & data!") не проходит, если удалить строку, то все собирается
При этом, символа __ram_image_end__ в ELF нет, а __ram_image_start__ есть

При этом кажется все флаги компилятора и линковщика соблюдены, порядок соблюден, дополнительные .o не линкуются.

Я бы попросил полный лог с перечнем команд исполнения, я бы даже сказал, что мне только хронология выполнения команд и нужна

 

[pvvx]

@pvvx , оказвается я собирал устаревшую v03.
Сейчас получше, но проверка ASSERT(__ram_image_end__ == 0x100020c0, "Error rom-bios-boot code & data!") не проходит, если удалить строку, то все собирается

Это значит, что неверно собрана область инициализации переменных ROM-BIOS.
Дальше - ваше собранное приложение = большой глюк.
Оставлено специально, т.к. если даны другие опции трансляции, влияющие на сборку структур и прочего (align и размеры bool), то система будет неверно обращаться к структурам WiFi и прочим в ROM.
Ещё бы по хорошему там надо ввести проверку 6-ти килобайтной сборки общей структуры WiFi, в которую входят к десятку структур с сотнями разных полей и описателей, чтобы полностью проверить правильно ли заданы опции транслятору...
Всё это можно выкинуть, но мне не нужен уровень качества Arduino (то работает, то нет, то через час виснет, ... ).
Решение написать собственный make на Питоне - это не мое решение