Там не только разрабы. Есть пользователи которые возможно честно хотят улучшить продукт, но не имеют не малейшего понятия о разработке. И если раньше такие ходили по репозиториям и заводили тикеты разной степень полноты и полезности, то теперь они могут "улучшать продукт" средствами AI. Буквально вчера мне в pet project прислали pr на 1000+ строк с описанием "Optimization and Enhancement" с кучей несвязаных изменений но пара из который выглядила ок. Когда я попросил разбить один pr на структурированные части чтоб принять часть автор извинился и признался что понятия не имеет как и что этот код делает и что мне надо сделать это самому ))
И для таких проектов как эмуляторы старого железа, старые кодеки и прочие проекты не завязанные на большие корпорации тут ситуация особенно интересна. Cобрать комьюнити тут сложно - поэтому посылать/банить потенциальных контрибьютеров как то не хочется. С другой стороны когда ты начинаешь тратить регурятную часть времени на низкокачественные pr - становится грусно.
То, что частоты не известны, как раз не страшно, мы их и определяем.
Там метод по сути состоит из 2х частей:
1 - это определение частоты, амплидуды и фазы для одной синусоиды и ее вычитание из исходного сигнала. Estimate делается через FFT, на основе того, что актуальная частота расположена в окрестности пика FFT спектра.
Этот шаг можно проделывать несколько раз, определяя каждый раз по синусоиде. Получаем набор параметров.
2 - оптимизация этого набора параметров.
Что то мне подсказывает что для задачи гитарного тюнера даже в таком виде должно работать, можно еще вначале отфильтровать все частоты выше скажем 4KHz чтоб снизить вероятность ошибок. Наверно можно еще применить фильтр 1го порядка прям начиная с 300-500Hz, чтоб еще поднять приоритет захвата основного тона.
Можно усложнить и повысить точность если делать оптимизацию после каждого шага выделения синусоиды, то есть 1) получили синусоиду с параметрами Ki, 2) добавили ее в существущий набор синусоид K, 3) прогнали оптимизацию для этого набора K, 4) проверили какой то критерий останова, 5) если не готово то переходим к шагу 1
Примерно так я у себя и делаю. На современных CPU это все еще работает в реальном времени даже без SIMD оптимизаций на 1м ядре. Хотя да, это кажется несколько расточительно в плане CPU.
Есть вот такая достаточно подробная статья, даже с кодом http://www.apsipa.org/proceedings_2009/pdf/WA-L3-3.pdf ну и моя попытка использовать предложенный там метод на практике https://github.com/dcherednik/libgha/ Работает достаточно хорошо, dtmf тоны определяет за менее чем 256 отсчетов (при 8000Гц). Сейчас я использую этот алгоритм в реализации AT3Plus совместимого кодека.
Еще подобной задачей занимались ребята из xiph при проектировании кодека ghost до того как переключились на опус. Но ghost так и не вышел, так что тут можно только изучать их материалы https://people.xiph.org/~xiphmont/demo/ghost/demo4.xhtml
update: проверьте, на всякий случай, правильно ли спектр построен, может там квадрат забыли)
Большая проблема при тунелировании через TCP - алгоритм Нагла, особенно в сочетании с отложенным ACK (а обычно это так и получается). Если выставить TCP_NODELAY на сокете, то уже будет сильно лучше. Применительно к openvpn кажется надо tcp-nodelay написать в конфиг.
К слову, стабилизаторы переменного напряжения на магнитных усилителях то же были, и даже сейчас еще можно найти Б2-2 или Б2-3 при желании, схемотехника у них простая и в то же время интересная.
Кажется так не сработает. Если на эмиттере vt2 0.63 в, то на его базе будет где то 1-1.2 в зависимости от примененного транзстора. Его база соеденена непосредственно с коллектором vt1. Однако для работы vt1 нужно чтоб напряжение на эмиттере было меньше чем напряжение на коллекторе. При подключении R6 к верхнему R4, напряжение в этой точке станет примерно (не учитывая ток через r3) то есть 1.2 вольта. Получается vt1 работает при практически нулевом, если не обратном напряжении э-к. Возможно при каких то транзисторах оно и заработает (нужно учитывать уже реальные Uбэ), но выглядет экстримально.
Тут скорее надо использовать на месте v1 pnp транзистор, соответственно перевернув весь этот узел - тогда это будет почти что класическая схема 70x.
Какую то вы совсем неудачную схему для повторения выбрали, разве что использовать ее как для работы над ошибками. Из того что бросается в глаза сразу:
vt5 vt7 - с одной стороны они управляются током vt4 vt6, что хорошо и несколько повышает линейность. С другой стороны нет пути для разряда емкостей переходов бэ и бк у выходных транзисторов, что скажется на быстродействии, приведет к сквоздным токам.
Глубина ООС по постоянному току никакая, термостабильность обеспечивается за счет RC цепей местных обратных связей
Чувстительность к питанию - все подавление пульсаций по питанию сводится к C9 R13.
Я не знаю какое там напряжение на эмиттере vt2, но нужно понимать что это напряжение уменшает максимальный размах на выходе усилителя напряжения.
нагрузкой vt2 в основном является достаточно низкое сопротивление R7, оно сильно ограничит коэффициент петлевого усиления.
Собственно вы и сами написали что для работы этой схемы тредуется 40ma тока покоя, что поверьте ооочень много)
Круто! Но ведь подобным образом были устроены двигатели ЛПМ магнитофонов с прямым приводом, тот же БС-02 от Веги или двигатели флоповодов. Или есть принципиальное отличие?
Я же не знаю устройства вашей проводки. Но чудес не бывает. Может у вас рядом с этой розеткой пол лучше ток проводит и поэтому вы чувствуете покалывания в этом месте, а в других местах не чувствуете. А может у вас в других розетках PE соединен с N (ни в коем случае нельзя так делать!). А может в других розетках потребители подключены через тройники и одни из других потребителей "заземлены" через кабель антенны, или как то еще. Можно много придумывать вариантов, вплоть до криворукого электрика. Но в пластик (если конечно он не обгорел) дающий заметную утечку верится слабо. В любом случае это легко проверить.
При чем тут напряжение на корпусе и производитель розетки?
В импульсных блоках питания на входе стоят 2 конденсатора, средней точкой соединенные с общим проводом (соответственно и с металическим корпусом) компьютера. Через них и образуется цепь через которую проходит ток при прикосновении к корпусу.
По хорошему если бы у вас был PE проводник (то самое заземление), то эта средняя точка была бы с ним соединена через третий контакт в розетке, и было бы все хорошо. Но сами написали что нет PE проводника - упс, в квартире ничего не поделаешь.
Тут нужно ставить x2 конденсатор, или какой другой предназначенный для работы в подобных цепях. Но есть шанс что по габаритам могут и не пройти. Китайские пленочные будут быстро "выгарать" теряя емкость.
Как автор atracdenc, могу чуть рассказать про ATRAC. Действительно, ничего прям особенного в ATRAC1 (это тот который SP) нет, там просто достаточно большой битрейт, более удачный чем у mp3 фильтрбанк, в частности он позволяет переключать размер окна в каждом из 3х полос. А в остальном ATRAC1 разрабатывался в то время когда каждый такт был на счету, в нем даже нет никакого энтропийного кодирования после квантования MDCT коэффициентов.
ATRAC3 чуть интереснее, уже есть кодировние Хаффмана, вместо переключения размера окна там используется нормализация уровня перед mdct - коэффициент аттенюации передается так же в потоке для последующего восстановления на декодере. Однако полностью реализовать эту фичу у себя мне не удалось. В остальном кодек очень похож на ATRAC1.
ATRAC3+ (не реализован в atracdenc) вот он имеет уникальную для аудиокодеков технологию - Generalized Harmonic Analysis, с ней было бы интересно поэкспериментировать. С другой стороны HiMD устройства, использующие этот кодек, я использовал, обещания Sony что на битрейте 64Kbit а ATRAC3+ достигнуто кажество SP режима не сбылись.
Эксперименты с фильтрбанками для которых я могу найти заведомо корректную реализацию говорят что да. Для фильтрбанка DTS кодека (реализация есть в ffmpeg), например, ошибка где то в 5м знаке после запятой была.
Предыстория? Я как то порывался статью написать, но все не мог себя заставить)) Аудио и видео кодеки всегда были мне интересны, еще до того как программировать стал. Потом как то сидел в отпуске и захотелось попробовать себя в чем то новом (по работе я не связан с DSP никак), стал читать код ffmpeg, увидел что там есть декодер для ATRAC, а когда то я был фанатом минидиска, ну тут все и совпало - решено написать енкодер по коду декодера из ffmpeg. ATRAC1 мне показался достаточно простым (стек из 2х QMF + MDCT + квантование в частотной области, ну еще опционально переключение размера окна), ну и стал постепенно изучать область и реализовывать. Особых сложностей с ATRAC1 в общем то не было, и достаточно быстро получился рабочий код, дающий в целом не плохой результат. Ну так и втянулся.
Потом взялся за ATRAC3 - он не сильно сложнее, другой фильтрбанк, но все еще имеющий в основе стек из QMF + MDCT, есть кодирование хаффмана. Из интересного, нет переключения размера окна, но есть gain modulation - возможность изменить уровень сигнала в пределах окна перед mdct в кодировщике и соответственно обратным образом изменить его после imdct в декодере, эта фича, кстати, до конца мной не была реализована. Тем не менее для LP2 режима (это что то в районе 132Kbit/s) качество получилось сравнимым с mp3 - 128.
Тем временем код на github заметили другие любители минидиска, и с удивлением для себя я обнаружил, что оказывается проект используют в том числе для заливки треков на минидиск теми кто по каким то причинам до сих пор ими пользуются)) А кто то собрал его под WebAssembly и предлагал как web сервис))
Тем не менее мне интереснее разбираться дальше, и ATRAC3Plus тут как раз интересен тем что использует Generalized Harmonic Analysis (GHA) для извлечения информации о тональных составляющих - в других кодеках такого подхода я не встречал, и было бы интересно поиграться с этим. Но ATRAC3Plus использует pqf для разбивки входного сигнала на 16 суб-полос перед mdct, и подозреваю что разные прототипы для синтеза и анализа, и тут я застреваю, поскольку дальше без понимания математики происходящего в pqf никак.
Анализирующий pqf это первое преобразование при кодировании, и соответственно синтезирующий pqf - последнее при декодировании. Все потери происходят сильно позже, уже после перехода в частотную область. Таким образом потерь я пока просто не допускаю, просто подаю результат работы своего анализирующего фильтрбанка на вход синтезирующего из ffmpeg. И ожидаю как минимум "near perfect reconstruction".
Коэффициенты часто записываются не последовательно для более простого кода их применения, так почти во всех кодеках, в том числе и opensource. Там же хитрое прореживание совмещенное со сверткой с частью прототипа. В dcaenc боле понятно https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/dcaenc.c#L319-L367 И вот форма этого прототипа сильно влияет на свойства фильтрбанка. В том же dca есть 2 фильтрбанка, для PR и NPR.
Там не только разрабы. Есть пользователи которые возможно честно хотят улучшить продукт, но не имеют не малейшего понятия о разработке. И если раньше такие ходили по репозиториям и заводили тикеты разной степень полноты и полезности, то теперь они могут "улучшать продукт" средствами AI.
Буквально вчера мне в pet project прислали pr на 1000+ строк с описанием "Optimization and Enhancement" с кучей несвязаных изменений но пара из который выглядила ок. Когда я попросил разбить один pr на структурированные части чтоб принять часть автор извинился и признался что понятия не имеет как и что этот код делает и что мне надо сделать это самому ))
И для таких проектов как эмуляторы старого железа, старые кодеки и прочие проекты не завязанные на большие корпорации тут ситуация особенно интересна. Cобрать комьюнити тут сложно - поэтому посылать/банить потенциальных контрибьютеров как то не хочется. С другой стороны когда ты начинаешь тратить регурятную часть времени на низкокачественные pr - становится грусно.
То, что частоты не известны, как раз не страшно, мы их и определяем.
Там метод по сути состоит из 2х частей:
1 - это определение частоты, амплидуды и фазы для одной синусоиды и ее вычитание из исходного сигнала. Estimate делается через FFT, на основе того, что актуальная частота расположена в окрестности пика FFT спектра.
Этот шаг можно проделывать несколько раз, определяя каждый раз по синусоиде. Получаем набор параметров.
2 - оптимизация этого набора параметров.
Что то мне подсказывает что для задачи гитарного тюнера даже в таком виде должно работать, можно еще вначале отфильтровать все частоты выше скажем 4KHz чтоб снизить вероятность ошибок. Наверно можно еще применить фильтр 1го порядка прям начиная с 300-500Hz, чтоб еще поднять приоритет захвата основного тона.
Можно усложнить и повысить точность если делать оптимизацию после каждого шага выделения синусоиды, то есть 1) получили синусоиду с параметрами Ki, 2) добавили ее в существущий набор синусоид K, 3) прогнали оптимизацию для этого набора K, 4) проверили какой то критерий останова, 5) если не готово то переходим к шагу 1
Примерно так я у себя и делаю. На современных CPU это все еще работает в реальном времени даже без SIMD оптимизаций на 1м ядре. Хотя да, это кажется несколько расточительно в плане CPU.
Есть вот такая достаточно подробная статья, даже с кодом http://www.apsipa.org/proceedings_2009/pdf/WA-L3-3.pdf ну и моя попытка использовать предложенный там метод на практике https://github.com/dcherednik/libgha/ Работает достаточно хорошо, dtmf тоны определяет за менее чем 256 отсчетов (при 8000Гц). Сейчас я использую этот алгоритм в реализации AT3Plus совместимого кодека.
Еще подобной задачей занимались ребята из xiph при проектировании кодека ghost до того как переключились на опус. Но ghost так и не вышел, так что тут можно только изучать их материалы https://people.xiph.org/~xiphmont/demo/ghost/demo4.xhtml
update:
проверьте, на всякий случай, правильно ли спектр построен, может там квадрат забыли)
Большая проблема при тунелировании через TCP - алгоритм Нагла, особенно в сочетании с отложенным ACK (а обычно это так и получается). Если выставить TCP_NODELAY на сокете, то уже будет сильно лучше. Применительно к openvpn кажется надо tcp-nodelay написать в конфиг.
К слову, стабилизаторы переменного напряжения на магнитных усилителях то же были, и даже сейчас еще можно найти Б2-2 или Б2-3 при желании, схемотехника у них простая и в то же время интересная.
Кажется так не сработает. Если на эмиттере vt2 0.63 в, то на его базе будет где то 1-1.2 в зависимости от примененного транзстора. Его база соеденена непосредственно с коллектором vt1. Однако для работы vt1 нужно чтоб напряжение на эмиттере было меньше чем напряжение на коллекторе. При подключении R6 к верхнему R4, напряжение в этой точке станет примерно (не учитывая ток через r3)
то есть 1.2 вольта. Получается vt1 работает при практически нулевом, если не обратном напряжении э-к.
Возможно при каких то транзисторах оно и заработает (нужно учитывать уже реальные Uбэ), но выглядет экстримально.
Тут скорее надо использовать на месте v1 pnp транзистор, соответственно перевернув весь этот узел - тогда это будет почти что класическая схема 70x.
Какую то вы совсем неудачную схему для повторения выбрали, разве что использовать ее как для работы над ошибками. Из того что бросается в глаза сразу:
vt5 vt7 - с одной стороны они управляются током vt4 vt6, что хорошо и несколько повышает линейность. С другой стороны нет пути для разряда емкостей переходов бэ и бк у выходных транзисторов, что скажется на быстродействии, приведет к сквоздным токам.
Глубина ООС по постоянному току никакая, термостабильность обеспечивается за счет RC цепей местных обратных связей
Чувстительность к питанию - все подавление пульсаций по питанию сводится к C9 R13.
Я не знаю какое там напряжение на эмиттере vt2, но нужно понимать что это напряжение уменшает максимальный размах на выходе усилителя напряжения.
нагрузкой vt2 в основном является достаточно низкое сопротивление R7, оно сильно ограничит коэффициент петлевого усиления.
Собственно вы и сами написали что для работы этой схемы тредуется 40ma тока покоя, что поверьте ооочень много)
Он же исорически был на C, только в 2013 его перевели на сборку c++ компилятором.
Интересно, а как у полуторавольтовых литиевых обстоят дела я глубоким разрядом?
Проблема почти всех алкалиновых - текут - дети забывают включенную игрушку и через пару дней все оказывается в утекшем электролите.
Круто! Но ведь подобным образом были устроены двигатели ЛПМ магнитофонов с прямым приводом, тот же БС-02 от Веги или двигатели флоповодов. Или есть принципиальное отличие?
Я же не знаю устройства вашей проводки. Но чудес не бывает. Может у вас рядом с этой розеткой пол лучше ток проводит и поэтому вы чувствуете покалывания в этом месте, а в других местах не чувствуете. А может у вас в других розетках PE соединен с N (ни в коем случае нельзя так делать!). А может в других розетках потребители подключены через тройники и одни из других потребителей "заземлены" через кабель антенны, или как то еще. Можно много придумывать вариантов, вплоть до криворукого электрика. Но в пластик (если конечно он не обгорел) дающий заметную утечку верится слабо. В любом случае это легко проверить.
При чем тут напряжение на корпусе и производитель розетки?
В импульсных блоках питания на входе стоят 2 конденсатора, средней точкой соединенные с общим проводом (соответственно и с металическим корпусом) компьютера. Через них и образуется цепь через которую проходит ток при прикосновении к корпусу.
По хорошему если бы у вас был PE проводник (то самое заземление), то эта средняя точка была бы с ним соединена через третий контакт в розетке, и было бы все хорошо. Но сами написали что нет PE проводника - упс, в квартире ничего не поделаешь.
Строки. Оптимистические блокировки работают на уровне строк.
Peertube попробовать?
Тут нужно ставить x2 конденсатор, или какой другой предназначенный для работы в подобных цепях. Но есть шанс что по габаритам могут и не пройти. Китайские пленочные будут быстро "выгарать" теряя емкость.
Как автор atracdenc, могу чуть рассказать про ATRAC. Действительно, ничего прям особенного в ATRAC1 (это тот который SP) нет, там просто достаточно большой битрейт, более удачный чем у mp3 фильтрбанк, в частности он позволяет переключать размер окна в каждом из 3х полос. А в остальном ATRAC1 разрабатывался в то время когда каждый такт был на счету, в нем даже нет никакого энтропийного кодирования после квантования MDCT коэффициентов.
ATRAC3 чуть интереснее, уже есть кодировние Хаффмана, вместо переключения размера окна там используется нормализация уровня перед mdct - коэффициент аттенюации передается так же в потоке для последующего восстановления на декодере. Однако полностью реализовать эту фичу у себя мне не удалось. В остальном кодек очень похож на ATRAC1.
ATRAC3+ (не реализован в atracdenc) вот он имеет уникальную для аудиокодеков технологию - Generalized Harmonic Analysis, с ней было бы интересно поэкспериментировать. С другой стороны HiMD устройства, использующие этот кодек, я использовал, обещания Sony что на битрейте 64Kbit а ATRAC3+ достигнуто кажество SP режима не сбылись.
Если он включен между сетевыми проводами (что скорее всего судя по емкости), то такой https://www.chipdip.ru/product0/9000549311
Дело в том что в сети возможны переходные процессы и выбросы напряжения до киловольта, конденсатор должен их выдерживать.
Эксперименты с фильтрбанками для которых я могу найти заведомо корректную реализацию говорят что да. Для фильтрбанка DTS кодека (реализация есть в ffmpeg), например, ошибка где то в 5м знаке после запятой была.
Предыстория? Я как то порывался статью написать, но все не мог себя заставить)) Аудио и видео кодеки всегда были мне интересны, еще до того как программировать стал. Потом как то сидел в отпуске и захотелось попробовать себя в чем то новом (по работе я не связан с DSP никак), стал читать код ffmpeg, увидел что там есть декодер для ATRAC, а когда то я был фанатом минидиска, ну тут все и совпало - решено написать енкодер по коду декодера из ffmpeg. ATRAC1 мне показался достаточно простым (стек из 2х QMF + MDCT + квантование в частотной области, ну еще опционально переключение размера окна), ну и стал постепенно изучать область и реализовывать. Особых сложностей с ATRAC1 в общем то не было, и достаточно быстро получился рабочий код, дающий в целом не плохой результат. Ну так и втянулся.
Потом взялся за ATRAC3 - он не сильно сложнее, другой фильтрбанк, но все еще имеющий в основе стек из QMF + MDCT, есть кодирование хаффмана. Из интересного, нет переключения размера окна, но есть gain modulation - возможность изменить уровень сигнала в пределах окна перед mdct в кодировщике и соответственно обратным образом изменить его после imdct в декодере, эта фича, кстати, до конца мной не была реализована. Тем не менее для LP2 режима (это что то в районе 132Kbit/s) качество получилось сравнимым с mp3 - 128.
Тем временем код на github заметили другие любители минидиска, и с удивлением для себя я обнаружил, что оказывается проект используют в том числе для заливки треков на минидиск теми кто по каким то причинам до сих пор ими пользуются)) А кто то собрал его под WebAssembly и предлагал как web сервис))
Тем не менее мне интереснее разбираться дальше, и ATRAC3Plus тут как раз интересен тем что использует Generalized Harmonic Analysis (GHA) для извлечения информации о тональных составляющих - в других кодеках такого подхода я не встречал, и было бы интересно поиграться с этим. Но ATRAC3Plus использует pqf для разбивки входного сигнала на 16 суб-полос перед mdct, и подозреваю что разные прототипы для синтеза и анализа, и тут я застреваю, поскольку дальше без понимания математики происходящего в pqf никак.
Вот такая история)
Анализирующий pqf это первое преобразование при кодировании, и соответственно синтезирующий pqf - последнее при декодировании. Все потери происходят сильно позже, уже после перехода в частотную область. Таким образом потерь я пока просто не допускаю, просто подаю результат работы своего анализирующего фильтрбанка на вход синтезирующего из ffmpeg. И ожидаю как минимум "near perfect reconstruction".
Коэффициенты часто записываются не последовательно для более простого кода их применения, так почти во всех кодеках, в том числе и opensource. Там же хитрое прореживание совмещенное со сверткой с частью прототипа. В dcaenc боле понятно https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/dcaenc.c#L319-L367 И вот форма этого прототипа сильно влияет на свойства фильтрбанка. В том же dca есть 2 фильтрбанка, для PR и NPR.
NPR обеспечивает подавление алиасинга только в соседних полосах, часто этого достаточно, так как за пределами соседних полос ослабление уже обычно более 90db, и этим можно пренебречь для задач аудио. Например вот тут https://www.researchgate.net/publication/221380083_A_method_to_convert_near-perfect_into_perfect_reconstruction_FIR_prototype_filters_for_modulated_filter_banks
описано получение из near perfect reconstruction, perfect reconstruction. Забавно, что perfect reconstruction уже не выглядит как sinc(x)/x а имеет некоторые "резкие изломы".
Почитаю еще раз, вашу предыдущую статью может какие идеи возникнут...