Преобразование в частотную область должно быть полностью обратимо (погрешности работы с вещественными числами оставим за кадром). А как без перекрытия из 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 или что похожее. Ставя на вход ОУ получим усиление с разомкнутой петлей ОС в сотни тысяч — нужно будет обязательно уделить внимание должной коррекции, а это уже совсем другая задача.
Кстати, а не изучали вопрос «почему так»? Кажется создать еще один стек при вызове clone(), указать туда %rsp и затем обслуживать его так же как и «основной стек», т.е. разрешить расти, не очень сложно.
Одна проблема видна сразу — на архитектурах с 32битными VA сложно определить на сколько отступить от предыдущего стека. Но может еще есть причины?
Когда вы вызвали mmap вы по сути сказали ядру, что вам нужен какой то диапазон виртуальных адресов. И если вы попробуете обратиться за пределами страниц этого диапазона, вы получите Segmentation Fault. Если же обратитесь внутрь диапазона и страница еще не отображена то — minor page fault и как результат отображенную страницу.
Для выделения памяти для стека, приложение mmap может не вызывать, вообще. Есть только знание ядра о том что адрес принадлежит стековой области, что адреса стека растут вниз и что можно отступить на сколько то байт от указателя на вершину стека — этого достаточно чтобы ядро отобразило страницу. Если не попали — Segmentation Fault.
Т.е. еще раз, выделения памяти на стеке вообще не приводят к mmap`ам. Это полностью прозрачный механизм для вашего приложения.
Если сильно пофантазировать, то наверно можно придумать некую архитектуру, где память для стека будет просить компилятор, но встаёт вопрос — а что если я хочу писать на ассемблере? Да и не дело это компилятора вставлять системные вызовы в код, и к тому же это завязка компилятор + ос, сразу минус в переносимости.
стек может (и обычно так и происходит) выделяться неявно. Грубо говоря, ядро проверяет как далеко от rsp произошел page fault и при необходимости отображает еще память. Мы же о платформах с mmu говорим?
Ну как самый минимум ядро должно выделить память под область стека. В некоторых продвинутых вариантах можно запретить выполнять код со стека, опять же ядру нужно знать об этом чтоб снять битик исполнения со страницы.
Выходное напряжение регулируется резисторами 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(). Надо почитать…
Одна проблема видна сразу — на архитектурах с 32битными VA сложно определить на сколько отступить от предыдущего стека. Но может еще есть причины?
Для выделения памяти для стека, приложение mmap может не вызывать, вообще. Есть только знание ядра о том что адрес принадлежит стековой области, что адреса стека растут вниз и что можно отступить на сколько то байт от указателя на вершину стека — этого достаточно чтобы ядро отобразило страницу. Если не попали — Segmentation Fault.
Т.е. еще раз, выделения памяти на стеке вообще не приводят к mmap`ам. Это полностью прозрачный механизм для вашего приложения.
Если сильно пофантазировать, то наверно можно придумать некую архитектуру, где память для стека будет просить компилятор, но встаёт вопрос — а что если я хочу писать на ассемблере? Да и не дело это компилятора вставлять системные вызовы в код, и к тому же это завязка компилятор + ос, сразу минус в переносимости.
Но ведь это не так. 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 аппаратно виртуализованным )))