Open-Source USB транспорт на PIC32MZ

[dortonyan]

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

Причина разработки своего транспорта - отсутствие в продаже USB транспортов с I2S входом для использования АЦП. Кроме того, те транспорты что есть в продаже не устраивали по тем или иным причинам (либо плохо сделана плата, либо большое потребление).
Раньше сдерживающим фактором было отсутствие uac2 драйверов. Однако с переходом на win10 с нативным драйвером данная проблема была решена.
Ну и вообще, т.к. на дворе 21-ый век, то для меня не понятно - почему uac2 еще не перекочевал в открытый доступ. Данная публикация призвана исправить такое досадное упущение.

Почему PIC32MZ: Преимущество перед ARM процессорами - встроенный USB HS мост и одновременно удобный компактный корпус с удобной распиновкой. А по сравнению с кмосом - низкое потребление: порядка 70..80мА максимум.

Изначально планировал использовать фреймворк (harmony configurator), однако по ходу выяснилось, что данный фреймворк генерирует только USB AUDIO приложение для формата Class 1.
Кроме того по форумам полно отзывов по касякам в фреймворке. Дорабатывать фреймворк оказалось крайне контр-продуктивно из-за жесточайшей инкапсуляции, громоздкого стека и отсутствия его описания.

Намаявшись с фреймворком принял решение писать свой код с нуля. Но очень скоро обломался, т.к. выяснилось что для PIC32 процессоров описание USB моста полностью отсутствует! Т.е. микрочип предлагает только пользоваться их кривыми фреймворками.
Однако на форуме микрочипа нашлись добрые люди, которые поделились исходниками своих проектов USB девайсов на PIC32MZ: https://www.microchip.com/forums/m1083508.aspx
Пользуясь данными примерами, а так же методом тыка, удалось написать свой достаточно эффективный код (итоговый размер с оптимизацией gcc компилятора уровня 2 - менее 16кБт).
Конечно код не такой красивый как в фреймворках, слабовата инкапсуляция. Зато, разобраться в нем и доработать под свои нужды гораздо проще. А главное проще обходить касяки периферии, которые как оказалось имеют место быть.
В частности есть не описанные в эррате проблемы с DMA модулями.

Что в итоге удалось реализовать на самом чипе, без обвеса дополнительными микросхемами:
1. Вывод стандартного стерео: 32bit 768kHz (Правда драйвер не отображает частоты выше 384к, но по факту 768к выводит). И сам модуль I2S пика позволяет выводить данные с частотой не выше 384к. 768к вывести тоже можно, но каким-то нестандартным интерфейсом, типа QSPI или параллельным портом.
2. Вывод многоканала: 8-каналов 32bit 192kHz (опробовал только в отладочном режиме, подробнее ниже).
3. Стерео вход: 32bit 768kHz (опробовал по факту только 192, т.к. мой АЦП больше не выдает).
4. Распознавание DoP формата и вывод из него стерео DSD-битстрима частотой до DSD256 включительно.
5. До кучи - добавлено CDC устройство (виртуальный COM-порт) для обмена данными с транспортом (в проекте используется в отладочном виде, на любые принятые данные отвечает строкой "CDC is works").

Вывод многоканала физически не реализован, т.к. изначально в транспорте он не предусматривался. Работу проверял в отладочном режиме, переключая на выход пары каналов по очереди (остальные каналы выводили данные в отладочные буферы).
Весь описанный выше функционал реализован на DMA модулях, благодаря чему хватает небольшой тактовой частоты процессора (160МГц для работы многоканала + стерео-входа).
Причем изначально вывод данных в I2S модули выполнялся на DMA с прерываниями. Однако, выяснилось, что прерывания DMA работаю криво, из-за чего модуль может самопроизвольно вырубаться.
Описал проблему на форуме микрочипа (в конце ветки), но - глухо как в танке: https://www.microchip.com/forums/FindPost/1219136

Пришлось выкручиваться по другому. В результате получилось даже лучше, т.к. передача данных между I2S буферами и FIFO данных получилась полностью аппаратной (DMA модули перегружаются автоматически в цикле).
Кроме того, для дополнительного снижения потребления добавлено 3 режима с разной тактовой частотой, в зав-ти от кол-ва каналов и выбранной ЧД.
В результате потребление от USB шины (контроллер + развязка) с питанием через step-down получилось от 40мА (стерео-вывод), до 55мА (8-каналов + стерео вход).
Отмечу, что в режиме FS (uac1) потребление можно опустить еще ниже: до 20..30мА, что может быть актуально для портативного девайса.

Проект сделан в IDE MPLabX 6.05, с компилятором CX32 v4.1. Проверялся только на win10. Актуальная схема транспорта ниже во вложении.
Конечно, нативный uac2 драйвер в win10 достаточно корявый, легко ломается сам и еще легче ложит винду (хватает ошибки в дескрипторе). Но готовый проект значительно облегчает отладку USB девайса, достаточно выпилить лишний функционал из дескриптора и обработчика команд.
Особенности конфигурации USB моста или DMA модуля я постарался подробно описать комментариями, но если у кого-то найдутся другие проблемы - можно обсудить в ветке ниже.

[Meta|_]

во всех новых процессорах есть аппаратные генераторы случайных чисел

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

Другое дело когда есть аппаратные блоки для какой-нить криптографии. Из них обычно можно сделать качественный и быстрый генератор псевдослучайных чисел. Но опять же, если это криптография мало-мальски сложная, то едва ли аппаратный сопроцессор выполнит что-то серьёзное (там раундовую функцию или функцию сжатия) за 1-2 такта. Скорее всего придётся инициировать некий процесс, он что-нить пошифрует-похеширует, по DMA положит в память, мы это узнаем по прерыванию и сможем использовать 100500 бит псевдослучайных чисел. Опять не супер изящно, но если подходит - можно использовать.

Есть другая мысль - попробовать разменять ОЗУ на время. Первый пример пришедший в голову:
Выделить пару килобайт ОЗУ, при старте заполнить их случайными данными (любым способом, хоть константами из флеша).
По мере необходимости побитно выбираем из этого массива псевдослучайные данные.
По мере обработки каждого 32-битного слова прибавляем к нему какую-нить константу (наверное, взаимно-простую с 2^32, например 3333333331).
По достижении конца массива зацикливаемся.

С криптографической точки зрения это, конечно, не ПСП. Но период получится достаточно большой и для наших задач будет, наверное, достаточно.

---------- Сообщение добавлено 00:56 ---------- Предыдущее сообщение было 00:19 ----------

едва ли аппаратный сопроцессор выполнит что-то серьёзное (там раундовую функцию или функцию сжатия) за 1-2 такта

Нет, наверное неправ.
Раундовую функцию за пару тактов выполнить как раз вполне реально. Если они действительно пошли по пути добавления в ядро инструкций для шифрования, то раунд какого-нить AES вполне может обсчитываться несколькими спец инструкциями и сформировать 128-512 бит неплохой ПСП.

[dortonyan]

Я вот прикинул, что в принципе для мультибитного вывода (даже х32 или х64) сойдет и стандартный LFSR. Особо быстрый генератор ПСП имеет смысл только для модулятора.
Но для модулятора - я не уверен что он нужен. Разницы (с дизером и без) не видно и не слышно.

Нет, я про вывод наружу из Пика PCM потоков быстрее х16. Например, х64.

Это понятно.
В общем такие кратности проще делать на плисине. х2 апсемплер с х32 до х64 без проблем сделает даже простая CPLD. Для 16-битных данных там расходуется порядка сотни ячеек (можно взять из проекта DF3E).

P.S.
Сравнил производительность копированием из USB FIFO через DMA и ядром.
Все таки DMA выгоднее.

[eclipsevl]

Мучал-мучал свою версию FIR, запилил расчет 2 входных стерео семплов за один проход. Пока что получается 2.5мкс/стерео семпл, на 192МГц.
Но у меня сделано с записью новых семплов в FIFO фильтра. Т.е. в теории можно вообще не копировать семплы с USB, а читать их в коде фильтра напрямую с FIFO USB. Так не нужно ни DMA, ни дополнительных операций копирования.

Посмотрите две мои версии, одна 1 семпл/проход, вторая - 2 семпла. В последней считает сразу два интерполированных семпла за проход, с перемножением в шахматном порядке. Думаю в Вашей версии можно подобную технику применить. Там конечно не совсем очевидный алгоритм, уже думаю может статейку написать
В синтетическом тесте с входным и выходным буфером в кешируемой памяти реально дойти до 2 мкс/семпл.
fir_interp_mips.zip

Пара комментариев по коду: там применяется свойство симметрии ИХ, указатели на отсчеты в кольцевом буфере в регистрах v0, v1. Я их в комментариях зову ptrx и ptry соответственно. ptrx стартует с самого нового семпла и идет в сторону старого, ptry с самого старого к новому, доходят до середины кольцевого буфера. Свертка разделена на две части: до перехода границы FIFO одним из указателей и после.

Алексей, а Вы тестировали аудио вход с WASAPI Exclusive Mode в Adobe Audition?
Там почему-то каждые 10мс пропадает часть семплов. Пытался отдебажить, никак. В REW таких проблем нет, Audacity WASAPI (shared) работает нормально. Еще с ASIO4ALL драйвером подобная проблема, тоже каждые 10мс затык.
Кстати для работы в AA WASAPI Exclusive пришлось добавить форматы 16/24 бит.

Повторил тест с XMOS девайсом и виндовыми драйверами - та же фигня. Драйвер что ли такой кривой в винде.

[dortonyan]

Т.е. в теории можно вообще не копировать семплы с USB, а читать их в коде фильтра напрямую с FIFO USB. Так не нужно ни DMA, ни дополнительных операций копирования.

Да, интересная идея.
Но у меня еще используется входной аттенюатор и обсчет выполняется по одному входному семплу, с последующим выходом в общий цикл, чтобы проц не сильно долго висел в обработке ЦФ.

Пара комментариев по коду: там применяется свойство симметрии ИХ, указатели на отсчеты в кольцевом буфере в регистрах v0, v1. Я их в комментариях зову ptrx и ptry соответственно. ptrx стартует с самого нового семпла и идет в сторону старого, ptry с самого старого к новому, доходят до середины кольцевого буфера. Свертка разделена на две части: до перехода границы FIFO одним из указателей и после.

У меня сделано аналогично: на паре указателей, по которым берутся данные из разных концов свертки, и которые отдельно проверяются на переход через конец FIFO буфера (тут других вариантов в общем-то и нету):

Скрытый текст

    // load address row 1
    ADDU $t8, $a0, 128
    // check addr overflow
    BLTU $t8, $a3, .fir1_shrp_p2
    SUBU $t8, $t8, $a3
    ADDU $t8, $t8, $a2
    .fir1_shrp_p2:
    
    // load address row 2
    ADDU $t9, $a0, 632
    // check addr overflow
    BLTU $t9, $a3, .fir1_shrp_p3
    SUBU $t9, $t9, $a3
    ADDU $t9, $t9, $a2
    .fir1_shrp_p3:
    
    // ------------ load 4 coefficients 5 --------------------------------------
    LI $v0, -1322
    LI $v1, 2202
    LI $s2, -3318
    LI $s3, 4683
    // load Left data samples
    LW $t0, 0($t8)
    LW $t1, 8($t8)
    LW $t2, 16($t8)
    LW $t3, 24($t8)
    LW $t4, 96($t9)
    LW $t5, 104($t9)
    LW $t6, 112($t9)
    LW $t7, 120($t9)
    // multiply-acccumulate Left
    MADD $ac0, $t0, $v0
    MADD $ac0, $t1, $v1
    MADD $ac0, $t2, $s2
    MADD $ac0, $t3, $s3
    MADD $ac0, $t4, $s3
    MADD $ac0, $t5, $s2
    MADD $ac0, $t6, $v1
    MADD $ac0, $t7, $v0
    // load Right data samples
    LW $t0, 4($t8)
    LW $t1, 12($t8)
    LW $t2, 20($t8)
    LW $t3, 28($t8)
    LW $t4, 100($t9)
    LW $t5, 108($t9)
    LW $t6, 116($t9)
    LW $t7, 124($t9)
    // multiply-acccumulate Right
    MADD $ac1, $t0, $v0
    MADD $ac1, $t1, $v1
    MADD $ac1, $t2, $s2
    MADD $ac1, $t3, $s3
    MADD $ac1, $t4, $s3
    MADD $ac1, $t5, $s2
    MADD $ac1, $t6, $v1
    MADD $ac1, $t7, $v0

[свернуть]

Далее еще три таких прохода до след. проверки адресов.
Думал запилить универсальную ф-ю, но потом забил. В принципе достаточно расписать смещения на один проход до инкремента адресов, дальше можно копипастом.
Ну и перебирать фильтры особо смысла нету. Оптиум и так понятен.

В синтетическом тесте с входным и выходным буфером в кешируемой памяти реально дойти до 2 мкс/семпл.

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

Алексей, а Вы тестировали аудио вход с WASAPI Exclusive Mode в Adobe Audition?

Не.
Только в плеерах: foobar, aplayer в режимах push, event.

Кстати для работы в AA WASAPI Exclusive пришлось добавить форматы 16/24 бит.

Да, я вот только вчера тоже добавил, иначе aplayer не хотел выводить.
Кстати, пробовал для 24-х бит задать в дескрипторах значение 3 байта на семпл. Помучался, но таки запилил обработку FIFO на 3-х байтовых семплах. Но звук так и не пошел.
У себя касяк не нашел, поэтому появились подозрения, что сам виндовский драйвер не умеет паковать данные в 3 байта.
Вы не пробовали такой вариант?

Повторил тест с XMOS девайсом и виндовыми драйверами - та же фигня. Драйвер что ли такой кривой в винде.

Очень может быть. После приключений с отладкой энумерации я уже ничему не удивляюсь.

---------- Сообщение добавлено 11:30 ---------- Предыдущее сообщение было 10:45 ----------

P.S.
Посмотрел вариант прохода в два семпла. Точно, можно же еще использовать свободные аккумуляторы! Отличная идея.
Тогда да, можно еще чутка вытянуть производительности.
Жаль с модулятором обработку нельзя распараллелить. Для DSD128 выхода если только упрощать модулятор и снижать порядок.

---------- Сообщение добавлено 12:02 ---------- Предыдущее сообщение было 11:30 ----------
P.P.S.
Подумал на счет копирования прямо из USB FIFO.
Действительно. Даже если на входе аттенюатор, то можно им и копировать, а FIR уже обсчитывать по семплу.
В общем тоже классная идея!

---------- Сообщение добавлено 12:44 ---------- Предыдущее сообщение было 12:02 ----------

P.P.P.S.
Прием обработки сразу двух семплов натолкнул меня на еще одну идею.
Можно обработать сразу 4 семпла всеми 4-мя аккумуляторами для одного канала. Тогда для обсчета правого канала потребуется по новой грузить коэф-ты, НО!
Если обрабатывать группами по 8 семплов (как в моем примере), то загрузка 8-ми семплов потребуется только для первого прохода, для остальных проходов нужно будет догрузить по одному семплу.
Т.е. получается фифо на регистрах процессора, аналогично как я делал для коротких фильтров:

Скрытый текст

    // load coefficients
    LI $v0, -26591
    LI $v1, 229059
    LI $t8, -1052136
    LI $t9, 5043972
    
    // ************ Left channel pass 1 *********************    
    // load 8 data samples
    LW $t0, 0($a0)
    LW $t1, 8($a0)
    LW $t2, 16($a0)
    LW $t3, 24($a0)
    LW $t4, 32($a0)
    LW $t5, 40($a0)
    LW $t6, 48($a0)
    LW $t7, 56($a0)
    // multiply-acccumulate
    MULT $t0, $v0
    MADD $t1, $v1
    MADD $t2, $t8
    MADD $t3, $t9
    MADD $t4, $t9
    MADD $t5, $t8
    MADD $t6, $v1
    MADD $t7, $v0
    // Copy intermediate sample
    LW $t0, 32($a0)
    SW $t0, 8($a1)
    // Shift, round and save 32bit result Left
    EXTR_R.W $t0, $ac0, 23
    SW $t0, 0($a1)

    // ************ Left channel pass 2 *********************
    // load next sample
    LW $t0, 64($a0)
    // multiply-acccumulate
    MULT $t1, $v0
    MADD $t2, $v1
    MADD $t3, $t8
    MADD $t4, $t9
    MADD $t5, $t9
    MADD $t6, $t8
    MADD $t7, $v1
    MADD $t0, $v0
    // Copy intermediate sample
    LW $t1, 40($a0)
    SW $t1, 24($a1)
    // Restore gain, round and get 32bit value
    EXTR_R.W $t1, $ac0, 23
    // save result to $a1 pointer
    SW $t1, 16($a1)
    
    // ************ Left channel pass 3 *********************
    // load next sample
    LW $t1, 72($a0)
    // multiply-acccumulate
    MULT $t2, $v0
    MADD $t3, $v1
    MADD $t4, $t8
    MADD $t5, $t9
    MADD $t6, $t9
    MADD $t7, $t8
    MADD $t0, $v1
    MADD $t1, $v0    
    // Copy intermediate sample
    LW $t2, 48($a0)
    SW $t2, 40($a1)    
    // Restore gain, round and get 32bit value
    EXTR_R.W $t2, $ac0, 23
    // save result to $a1 pointer
    SW $t2, 32($a1)
    
    // ************ Left channel pass 4 *********************
    // load next sample
    LW $t2, 80($a0)
    // multiply-acccumulate
    MULT $t3, $v0
    MADD $t4, $v1
    MADD $t5, $t8
    MADD $t6, $t9
    MADD $t7, $t9
    MADD $t0, $t8
    MADD $t1, $v1
    MADD $t2, $v0    
    // Copy intermediate sample
    LW $t3, 56($a0)
    SW $t3, 56($a1)
    // Restore gain, round and get 32bit value
    EXTR_R.W $t3, $ac0, 23
    // save result to $a1 pointer
    SW $t3, 48($a1)

[свернуть]

По идее таким образом можно еще ускорить обсчет свертки чуть ли не вдвое.
Еще немного, и золотой ключик (ЦФ на STM8) у нас в кормане.

[eclipsevl]

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

минимум у меня вышел в пересчете на инструкции 842. Но у меня еще есть идея как из цикла выбросить одну инструкцию, тогда как раз 800 остается.

Не.
Только в плеерах: foobar, aplayer в режимах push, event.

Я наоборот, про ввод аудио по USB.

Кстати, пробовал для 24-х бит задать в дескрипторах значение 3 байта на семпл. Помучался, но таки запилил обработку FIFO на 3-х байтовых семплах. Но звук так и не пошел.
У себя касяк не нашел, поэтому появились подозрения, что сам виндовский драйвер не умеет паковать данные в 3 байта.
Вы не пробовали такой вариант?

Я в 24 бит варианте указал 4 байтовые семплы, 3 не пробовал.

Жаль с модулятором обработку нельзя распараллелить.

разве что векторные операции использовать, но там разрядность 16 бит.

[dortonyan]

разве что векторные операции использовать, но там разрядность 16 бит.

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

---------- Сообщение добавлено 13:32 ---------- Предыдущее сообщение было 13:29 ----------

P.S.
Еще пришла мысль по поводу USB FIFO.
Так может оно не просто так FIFO называется? Может считывать сразу весь пакет не обязательно?
Просто подтвердить, что принято, а читать данные по мере надобности.

---------- Сообщение добавлено 13:37 ---------- Предыдущее сообщение было 13:32 ----------

Попробовал. Не, так нельзя, надо считывать сразу весь пакет. Ну или флаг устанавливать только когда прочитано кол-во указанное в RXCNT регистре.

[Alexander]

Offтопик:
Всё конечно очень занимательно, но может лучше второй МК добавить? Первый будет занят обменом с РС и буферизацией а второй форматами и выводом, не?
Не ругайтесь сильно я не програмист, но такая мысль пришла в голову после прочтения нескольких последних страниц, чувство такое, что в один PIC все хотелки не полезут.

[dortonyan]

Offтопик:
Alexander, это больше спортивный интерес.
Если добавлять второй чип, то лучше сразу FPGA, которая легко закроет все возможные хотелки.

[Turbo_man]

Ну как я понимаю, все хотелки уже влезли. Осталось сделать все модули максимально качественными. Довести их до перфекта.

[Alexander]

Offтопик:

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

Не стоит забывать о цене и наличии (с некоторых пор).

как я понимаю, все хотелки уже влезли

И варианты вывода под разные DAC предусмотрены? На втором МК это можно было-бы устроить.

[Михаил45]

FPGA на Али сколько хочешь для нужд радиолюбителя. Вопрос же не в их применении.

[antecom]

Пытаюсь вывести многоканал. Удалось это сделать только для Wasapi Shared (в Foobar и Adobe Audition).
В Exclusive работает только двухканальный вывод. При выводе многоканала выдается ошибка - Unrecoverable playback error: Unsupported stream format: 44100 Hz / 32-bit / 8 channels (0x63F)

Все бы ничего, но во первых, biperfect есть только если частота дискретизации файла совпадает с выставленной в свойствах аудиоустройства в Win10. Т.е. нужно либо все апсемплить до какой то одной частоты, либо каждый раз при смене Fs переключать её в винде. Либо винда будет апсемплить сама. Во вторых, вывод многоканала через HQPlayer и Roon не работает вообще.

Подскажите, плиз, куда копать.

[dortonyan]

Пытаюсь вывести многоканал. Удалось это сделать только для Wasapi Shared (в Foobar и Adobe Audition).
В Exclusive работает только двухканальный вывод. При выводе многоканала выдается ошибка - Unrecoverable playback error: Unsupported stream format: 44100 Hz / 32-bit / 8 channels (0x63F)

Выше только недавно писали, что и у меня, и у Владислава эксклюзив не работал, пока не добавили поддержку 24 и 16 бит форматов.
Для 24 бит ничего кроме дескриптора править не требуется, т.к. можно выводить в том же 4-байтовом формате.
А для 16 бит надо еще дорабатывать конфигурацию DMA под вывод 2-байтовыми словами.
Ну и после добавления в проект РГ я еще нашел касяки в обработчике команд хоста. Как доделаю DSP проект - поправлю проект для многоканального транспорта.

Offтопик:

Не стоит забывать о цене и наличии (с некоторых пор).

FPGA стоит не дороже пика. И достать наверное даже проще.

[antecom]

Выше только недавно писали, что и у меня, и у Владислава эксклюзив не работал, пока не добавили поддержку 24 и 16 бит форматов.
Для 24 бит ничего кроме дескриптора править не требуется, т.к. можно выводить в том же 4-байтовом формате.
А для 16 бит надо еще дорабатывать конфигурацию DMA под вывод 2-байтовыми словами.
Ну и после добавления в проект РГ я еще нашел касяки в обработчике команд хоста. Как доделаю DSP проект - поправлю проект для многоканального транспорта.

Алексей, спасибо! Будем ждать

[eclipsevl]

Сделать ASRC. Я в пятницу поковырял пару моделей, можно попробовать с квадратичной аппроксимацией уместить.

На низких частотах интерполяция Лагранжа 3 степени все красиво:
1.5кГц, 0дБ

Но на частотах повыше (тут 12кГц) уже не очень:

12кГц, 0дБ


Видимо надо пробовать более высокие порядки, -100дБ как-то не очень. На 20 кГц еще хуже будет. Есть конечно вероятность что у меня где-то ошибка...
Это причем уже с учетом апсемплинга до 352.8/384кГц.

В целом сам FD FIR не такой сложный для расчета, если подготовить LUT. Основные вычисления будут в интерполяторе/дециматоре.

[Turbo_man]

eclipsevl, asrc тема интересная. А можно в любую частоту ресемплить? Например, можно ли мастерклок 50МГц использовать как 1024фс для 48828,125 Гц и его кратные? Или только для 44,1<-->48 кГц?
Хочется попробовать 44,1 и 48 кГц >--> 48,828 кГц.

[dortonyan]

Видимо надо пробовать более высокие порядки, -100дБ как-то не очень.

Возможно.
Хотя в примере от ксайлинкс на полиноме 3-го порядка вроде нормально все.

[eclipsevl]

Возможно.
Хотя в примере от ксайлинкс на полиноме 3-го порядка вроде нормально все.

Xilinx с 64 фазами и FIRом 4096 порядка, и показывают только 1кГц.
во втором случае полином 4-го порядка, и видно что на 20кГц гармоники чуть ниже 120дБ

На МК посчитать аппроксимацию более высокого порядка дешевле чем интерполяцию.


Здесь две гармоники - 1.5 и 19.5 кГц.

eclipsevl, asrc тема интересная. А можно в любую частоту ресемплить? Например, можно ли мастерклок 50МГц использовать как 1024фс для 48828,125 Гц и его кратные? Или только для 44,1<-->48 кГц?
Хочется попробовать 44,1 и 48 кГц >--> 48,828 кГц.

В теории конечно да, но сейчас я хочу попробовать ASRC без определения соотношения частот "на лету": для ввода/вывода данных по USB из/в другую сетку частот.

[tomtit]

На МК посчитать аппроксимацию более высокого порядка дешевле чем интерполяцию.

Странно, я всегда считал, что линейная аппроксимация полиномом - это короткий КИХ.
Вроде есть даже теорема об эквивалентности.

[eclipsevl]

Странно, я всегда считал, что линейная аппроксимация полиномом - это короткий КИХ.
Вроде есть даже теорема об эквивалентности.

Так и есть. Речь о том что посчитать х8 интерполяцию и полином 8 порядка быстрее чем х16 и полином 3 порядка.

Вообще говоря, это банк коротких КИХ фильтров. При вычислении на МК это перемножение матрицы на вектор отсчетов.