Спасибо за проект, недавно закупался — активно пользовался. Из пожеланий, нет желания при тестировании измерять акустический шум лампы? В моем случае оказалось что Wolta 25Y55BL9E27 (модель по памяти) издает слабый шум, похожий на звон дросселя в цепи 50Гц. Предположу что виноваты импульсы перезарядки конденсатора после выпрямителя на входе. Кстати похожий эффект наблюдается и у некоторых КЛЛ, так что вряд ли это единичный случай.
Как минимум, при вертикальном монтаже резисторов, очень вероятно, что из за вибраций он своим выводом до чего нибудь дотронется. Да и транзисторы не мешало бы закрепить.
Преобразование в частотную область должно быть полностью обратимо (погрешности работы с вещественными числами оставим за кадром). А как без перекрытия из N спектральных коэффициентов восстановить все 2N исходных семпла?
Преимущества MDCT как раз в том, что перекрытие фреймов позволяет просто решить проблему блочных артефактов. И да, реализация mdct «в лоб» приведет к перекрытию в 50%.
The inverse MDCT is known as the IMDCT. Because there are different numbers of inputs and outputs, at first glance it might seem that the MDCT should not be invertible. However, perfect invertibility is achieved by adding the overlapped IMDCTs of subsequent overlapping blocks, causing the errors to cancel and the original data to be retrieved; this technique is known as time-domain aliasing cancellation (TDAC).
Т.e требуется перекрытие между фреймами. Без этого даже без квантования будут щелчки и слышимые искажения.
Наверно, стоит упомянуть про общий tradeoff преобразований в частотную область. А именно временная точность против частотной.
Предположим вы взяли 4096 сэмплов, сдалали mdct, получили 4096 спектральных коэффициентов, отбросили часть их них. В результате, грубо говоря, на протяжении почти 100 ms вы внесли искажения в какой то частотной области. С другой стороны если взять 64 семпла, получить 64 коэффициента и отбросить один из них то искажения затронут уже достаточно широкий частотный участок, хотя и на совсем короткое время. Поэтому практически все кодеки, умеют переключать размер фрейма в зависимости от характера входного сигнала, но проблема в том что иногда нам нужно и то и другое одновременно.
Поправьте если я не прав. Но ведь mpeg1 layer2 (как и musepack) является чистым subband кодеком и делает FFT только для психоакустики, и хаффмана, кажется, там нет.
mdct после разбиения на полосы и хаффман появились в mpeg1 layer3
Почему же? Это вполне себе последовательная общая ООС по напряжению. Напряжение ОООС на R4 C3 оказывается приложенным последовательно со входным сигналом.
На самом деле не симметричный каскад не панацея, у Дугласа Селфа многие проблемы описаны. Тут же класс А к тому же. Хотя зависимость h21 от Ik у T3 может себя проявить. В общем не знаю, давно хочу с этой схемой поиграться, но все никак ))
А про ОУ на вход — тогда уж лучше взять LM3886 или что похожее. Ставя на вход ОУ получим усиление с разомкнутой петлей ОС в сотни тысяч — нужно будет обязательно уделить внимание должной коррекции, а это уже совсем другая задача.
Выходное напряжение регулируется резисторами R1 и R2.
Но ведь это не так. R2 задаёт ток через стабилитрон, R1 можно считать простейшей защитой от КЗ, разгрузкой регулирующего транзистора, элементом RC фильтра — но точно не регулятором выходного напряжения.
Выходное напряжение в подобной схеме — константа, Uст-Uбэ. Напряжение на стабилитроне, в рабочем режиме, как раз мало зависит от проходящего через него тока. Другими словами если эти вышеупомянутые резисторы ощутимо влияют на выходное напряжение, но скорее всего стабилизатор не работает.
И все таки, вынося высокочастотные элементы на проводках, вы вносите дополнительные индуктивности и емкости в схему. Как минимум время переключения транзисторов может увеличится, что приведет к повышенному нагреву последних (а вы им еще и радиаторы спилили). Вы пульсации под нагрузкой, КПД до и после переделки сравнивали? Импульсный блок питания — высокочастотное устройство, а в таких штуках конструкция имеет большое значение.
Немного добавлю:
Все верно, XEN работает уровнем ниже чем ядро операционной системы (т.е. является гипервизором первого типа), причем XEN появился раньше чем в x86 появилcя VT-x (кстати по этому поводу в таблице не совсем правильно написано). Данный режим работы был назван паравиртуализацией. Если коротко, ядро переносится в RING1(если x86) или RING3(если x86-64, как раз тот редкий случай когда еще один уровень привилегий был полезным), все привилегированные инструкции в ядре заменяются на гипервызовы, меняется код начальной загрузки, устанавливается механизм обмена сообщений между гипервизором и ядром. Вместо эмуляции устройств, XEN использовал собственный backend — frontend механизм. Такую модификацию необходимо произвести как в Dom0 так и в DomU. Грубо говоря, xen с точки зрения ядра является еще одной архитектурой. Такой подход позволил получить неплохую производительность виртуальных машин даже без VT-x, но естественно данный подход применим только для операционных систем с открытым исходным кодом.
С появлением VT-x и аналогов у AMD в XEN появился режим аппаратной виртуализации HVM, который уже не требовал модификации гостевых ОС для работы. Однако поскольку эмуляция устройств является достаточно дорогой, то пришла необходимость в использовании паравиртуальных драйверов, для минимизации расходов на эмуляцию оборудования.
Однако, на сегодняшний день, Dom0 должен быть паравиртуализован полностью (отсюда вылезают неприяные моменты на x86-64, вроде невозможности эффективно выполнять системные вызовы через syscall). Однако в сообществе XEN есть идеи как сделать dom0 аппаратно виртуализованным )))
К сожалению популяризация не научных подходов, странных теорий и подобных вещей прямо или косвенно идет на руку тем кто хочет заработать на не знании кого либо чего либо. Погуглите, к примеру, «минимизатор мощности», на своём сайте автор уже продаёт данное устройство. Но дело даже не в 1000р потраченных на пару тиристоров, и не в потраченном времени, данное устройство просто опасно для использования. Естественно об этом ни чего не сказано. И это только один из примеров, посмотрите на псевдофармацевтику например, сколько средств от трудноизлечимых болезней похожим образом продвигаются в массы, несколько статей на неспециализированных форумах, подставные отзывы и можно делать бизнес на продаже «одуванчиков», о последствиях думаю говорить не стоит, в лучшем случае человек потеряет деньги, в худшем — время на своевременное лечение.
Кроме того плавиковая кислота отлично вытравливает кремний и его соединения, интересно что будет при длительном пребывании оборудования в атмосфере продуктов разложения данной жидкости. Или расчет на то что жидкость испарится раньше чем начнет разлагаться?
Преимущества MDCT как раз в том, что перекрытие фреймов позволяет просто решить проблему блочных артефактов. И да, реализация mdct «в лоб» приведет к перекрытию в 50%.
Т.e требуется перекрытие между фреймами. Без этого даже без квантования будут щелчки и слышимые искажения.
Предположим вы взяли 4096 сэмплов, сдалали mdct, получили 4096 спектральных коэффициентов, отбросили часть их них. В результате, грубо говоря, на протяжении почти 100 ms вы внесли искажения в какой то частотной области. С другой стороны если взять 64 семпла, получить 64 коэффициента и отбросить один из них то искажения затронут уже достаточно широкий частотный участок, хотя и на совсем короткое время. Поэтому практически все кодеки, умеют переключать размер фрейма в зависимости от характера входного сигнала, но проблема в том что иногда нам нужно и то и другое одновременно.
mdct после разбиения на полосы и хаффман появились в mpeg1 layer3
На самом деле не симметричный каскад не панацея, у Дугласа Селфа многие проблемы описаны. Тут же класс А к тому же. Хотя зависимость h21 от Ik у T3 может себя проявить. В общем не знаю, давно хочу с этой схемой поиграться, но все никак ))
А про ОУ на вход — тогда уж лучше взять LM3886 или что похожее. Ставя на вход ОУ получим усиление с разомкнутой петлей ОС в сотни тысяч — нужно будет обязательно уделить внимание должной коррекции, а это уже совсем другая задача.
Подозреваю, что сейчас это поведение регулируется флагами вызова clone(). Надо почитать…
Но ведь это не так. R2 задаёт ток через стабилитрон, R1 можно считать простейшей защитой от КЗ, разгрузкой регулирующего транзистора, элементом RC фильтра — но точно не регулятором выходного напряжения.
Выходное напряжение в подобной схеме — константа, Uст-Uбэ. Напряжение на стабилитроне, в рабочем режиме, как раз мало зависит от проходящего через него тока. Другими словами если эти вышеупомянутые резисторы ощутимо влияют на выходное напряжение, но скорее всего стабилизатор не работает.
Все верно, XEN работает уровнем ниже чем ядро операционной системы (т.е. является гипервизором первого типа), причем XEN появился раньше чем в x86 появилcя VT-x (кстати по этому поводу в таблице не совсем правильно написано). Данный режим работы был назван паравиртуализацией. Если коротко, ядро переносится в RING1(если x86) или RING3(если x86-64, как раз тот редкий случай когда еще один уровень привилегий был полезным), все привилегированные инструкции в ядре заменяются на гипервызовы, меняется код начальной загрузки, устанавливается механизм обмена сообщений между гипервизором и ядром. Вместо эмуляции устройств, XEN использовал собственный backend — frontend механизм. Такую модификацию необходимо произвести как в Dom0 так и в DomU. Грубо говоря, xen с точки зрения ядра является еще одной архитектурой. Такой подход позволил получить неплохую производительность виртуальных машин даже без VT-x, но естественно данный подход применим только для операционных систем с открытым исходным кодом.
С появлением VT-x и аналогов у AMD в XEN появился режим аппаратной виртуализации HVM, который уже не требовал модификации гостевых ОС для работы. Однако поскольку эмуляция устройств является достаточно дорогой, то пришла необходимость в использовании паравиртуальных драйверов, для минимизации расходов на эмуляцию оборудования.
Однако, на сегодняшний день, Dom0 должен быть паравиртуализован полностью (отсюда вылезают неприяные моменты на x86-64, вроде невозможности эффективно выполнять системные вызовы через syscall). Однако в сообществе XEN есть идеи как сделать dom0 аппаратно виртуализованным )))