• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

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

New member
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

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

pvvx

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

mikush

New member
То, что есть жрет 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

New member
я с Вами соглашусь на счет качества, да и мои скудные познания в схемотехнике (дак , усилитель и их питание )все качество входного потока умножит на ноль, просто спортивный интерес.
на хеликсе 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 и предлагают “как разработчику” бесплатные образцы их продукции… Вот на кого бы это всё свалить?
 
Последнее редактирование:

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

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

Код:
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 драйверу, что даст ещё десятки кило с увеличением возможностей... Думаю, что вашему питону придется потрудиться, распутывая это всё :)
 
Последнее редактирование:

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

Member
@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 на Питоне - это не мое решение :)
 
Последнее редактирование:
Сверху Снизу