Совсем недавно мы купили новый ноутбук на Windows человеку, который до сих пор пользовался Mac'ами. Одна из замеченных проблем - при просмотре видео звук в Bluetooth наушниках запаздывает по отношению к видео, причём заметно. Используя slow motion видео на телефоне, мы выяснили, что задержка составляет порядка 200мс. Это много, и это мешает воспринимать речь в видео. В то же время, на маке нет задержки. Почему так? Давайте разбираться. Воспроизводимый звук всегда будет отставать от источника. Часть этого отставания вызвана вполне физическими процессами - информация о звуке (в виде электронных сигналов) и собственно звук (в виде колебаний среды) должны дойти до наших ушей. Например, наблюдаемые 200мс - это время, за которое звук преодолевает примерно 70 метров в воздухе. Иными словами, если бы мы сидели в 70 метрах от ноутбука, 200мс было бы вполне ожидаемой задержкой. Однако, мы не сидим в 70 метрах. А свет распространяется настолько быстро, что временем на распространение электронных сигналов можно пренебречь. Тут на первый план выходит задержка на программную обработку сигнала и буферизацию. Bluetooth - беспроводная связь, подверженная шумам и требующая разных согласований и разделений между устройствами, поэтому данные нельзя передавать в реальном времени. Чтобы звук шёл плавно, нужно на устройстве иметь достаточно большой буфер, который (почти) никогда не заканчивается - если передача застряла по любой причине, устройство продолжит играть звук из буфера.  Это очень краткое и грубое объяснение, если хотите подробностей - см. здесь. Главное, что нам нужно знать - через Bluetooth задержка неизбежна. Это вам не проводные наушники (хотя и там есть небольшая задержка). Есть aptX LL, который должен снижать задержку для интерактивных приложений, но ни наушники, ни ноут этого протокола не поддерживают. Значит, так или иначе у нас будет минимум ~130мс задержки. Окей, но ведь мак выводит звук без задержки? На самом деле, это не так. Если провести эксперимент и, написав примитивный HTML, заставить мак вывести аудио неожиданно, мы увидим те же самые ~200мс задержки.  Когда воспроизводится видео (ютуб), мак задерживает видеопоток, чтобы синхронизировать картинку и звук. Это нормально, потому что если видео начнёт воспроизводиться на 200мс позже, вы этого не заметите. Из разных источников, которые сейчас я уже не найду, я выяснил, что мак спрашивает у наушников, через сколько времени они выведут звук, и выводит видео с такой же задержкой.  То есть, мак обманывает нас и тем самым устраняет видимую задержку, хотя физически задержка всё ещё на месте. Я хочу быть обманутым!  Почему же винда этого не делает? Сие есть тайна великая. Цель этой статьи - не разрешить эту загадку, а исправить положение дел хоть как-нибудь.  Цель: заставить хром под виндой выводить видео с задержкой, чтобы аудио и видео синхронизировались. При этом хотелось бы, чтобы при обновлении хрома/винды всё не сломалось. Мы не будем пытаться узнать у bluetooth устройства, какая у него задержка, потому что писать драйвера под винду у меня сертификата нет. Мак не может задерживать всё видео подряд, потому что тогда весь интерфейс будет на 200мс в прошлом. Значит, он сообщает в Chrome задержку, и тот уже задерживает видео.  И действительно, можно найти вот это место в коде хрома, где аудиопоток запрашивает задержку, и вот эту функцию, где данные получаются из системы. Под виндой, как ни странно, тоже есть похожий код, который опирается на функцию IAudioClock::GetPosition. Вот только винда не сообщает реальную позицию на аудио-устройстве, а учитывает только время на формирование потока данных. Я потратил пару часов на анализ того, как GetPosition работает, и что означают записи в реестре по адресу HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\{GUID}\Parameter Коротко говоря, я так и не понял. Разбираться в кишках GetPosition и её взаимодействий с остальным стеком без исходников очень тяжело. Это COM, весь построенный на интерфейсах, и там чёрт ногу сломит. Обидно: если бы можно было изменить какое-нибудь значение в реестре и указать задержку, проблема была бы решена... Но ладно, мы выяснили, что хром готов к задержке под виндой, вот только она о ней не сообщает. А давайте проверим, что будет, если бы сообщала? Качаем исходники хрома, настраиваем сборку, и патчим этот код вот так: Собираем и запускаем по оф. инструкции. Прошло 6 часов сборки, хром запустился. И видео стало опережать аудио на ~200 мс! Значит, предположение верно, хром может делать задержку. Мы теперь можем пропатчить хром и, скажем, добавить флаг в chrome://flags, чтобы задавать задержку. Но я могу себе представить, насколько такой флаг понравится хрому. И времени это займёт уйму, и шанс на успех не очень уж большой. Особенно если учесть аналогичный баг под линуксом. COM можно перехватывать, если внедрить в Chrome свою DLL, и тогда можно будет управлять возвращаемым из GetPosition значением, чтобы подкручивать задержку так, как нам хочется. Это решение хорошо по нескольким причинам: Не сломается с обновлением хрома. Будет работать с любой программой, использующей такой же метод доступа к аудио. Быстро реализуется. Но есть одна большая проблема: мы собираемся внедрять DLL в Chrome. Chrome - это браузер, и он очень активно защищается от любого вида внедрений кода, по понятным причинам. Например, здесь описываются защиты, и они довольно серьёзные. Главное ограничение, которое для нас важно - можно динамически грузить только библиотеки, подписанные ключом Microsoft. Шансов, что MS подпишет нашу библиотеку, не то что бы совсем нет, но величина эта из разряда особо малых.  С другой стороны, есть гитхаб проекта, который внедряет DLL в хром! См. тут. Качаем проект, запускам-проверяем, и видим любопытное: Значит, хром не так уж и защищается? Потираем руки и пишем свою DLL.  Если коротко, работу DLL можно описать так: построить IAudioClock как-нибудь, и пропатчить его vftable (таблицу виртуальных функций), что автоматически изменит все остальные IAudioClock.  Строим IAudioClock как-нибудь: Всё довольно просто и, в целом, следует гайду MS по получению аудио клиента (например, этому). Замечательно, теперь давайте пропатчим полученный вышеpClock: Единственное, что неочевидно - откуда брать эту четвёрку, номер функции в vftable. Если посмотреть на IAudioClock(тут), видно, что GetPosition в нём под вторым номером ( на MSDN по алфавиту). При этом IAudioClock наследует от IUnknown, в котором три функции (QueryInterface, AddRef, Release). Значит, наша GetPosition - пятая, и имеет смещение 4. DLL в первом приближении готова, и надо проверить её. Я написал примитивную программу, которая ничего особо не делает, только вызывает GetPosition, и внедрил DLL в неё. И всё отработало! Я воспользовался тем же самым инжектором, который уже работал, и внедрил библиотеку в хром.  Внедрение происходит более-менее стандартным способом: выделяется участок памяти под путь к файлу с DLL, и создаётся поток с точкой входа на LoadLibrary. Поскольку эта функция принимает ровно один аргумент, его можно передать в CreateRemoteThread, и поток загрузит DLL. Из забавного только то, что kernel32.dll, в которой LoadLibrary находится, не подвержена ASLR, и поэтому её функции всегда имеют один и тот же адрес во всех процессах (одинаковой архитектуры). Поэтому можно найти LoadLibrary в своём процессе и вызвать по тому же адресу в другом. Итак, я загрузил DLL, и... ничего не произошло. Библиотека внедрилась в хром, но GetPosition не вызывался!  Я приаттачился к chrome.exe дебаггером, и увидел, что GetPosition действительно не вызывается. Что за дела? Оказывается, за звук в Chrome отвечает особая подсистема, называемая audio.mojom.AudioService. И это отдельный процесс хрома, в который инжектор не инжектит, из-за вот этой вот проверки. Если проверить в этом процессе дебаггером, видно, что GetPosition вызывается. Не беда, убираем проверку, запускаем, и... ничего! Библиотека не появляется в списке библиотек.  Вы знаете, как удобно отлаживать внедрение библиотеки? Учитывая, что это извне созданный поток, который выполняет одну единственную функцию LoadLibrary? И что эта функция возвращает bool, а ошибка получается через GetLastError, которая для каждого потока своя? Я отвечу - вообще неудобно! Пришлось приаттачиться к процессу chrome.exe, поставить точку останова в LoadLibrary, и после этого вызвать создание потока. Ошибка - STATUS_INVALID_IMAGE_HASH, и это означает, что включилась защита хрома. Эта ошибка возвращается, если библиотека не подписана Microsoft. См. здесь, страница 29. Получается, хром не защищает корневой процесс, но защищает детей, включая аудио-подсистему. Ой.  Но ведь мне дают создать поток в хроме и память читать-писать! И вообще, а как же отладчики это всё делают? Если гора не идёт к Магомету... Давайте сделаем ручками. Что такое импорт DLL? Что такое делает LoadLibrary, чего мы не можем сделать вручную? Для нормальной работы DLL нужны следующие действия по её загрузке: Загрузить DLL в память процесса. Настроить reloc'и. Настроить импорты. Передать управление в DllMain. И всё это мы, в целом, можем сделать сами. Часть операций будет производить внешний процесс (выделение памяти, копирование, создание потока), а часть (настройка reloc'ов и импортов, вызов DllMain) - код загрузчика, который внешний процесс внедряет в chrome.exe. Код загрузчика (loader'а) должен быть PIC, то есть, poisition-independent, и не должен вызывать никаких библиотечных функций. Тогда этот код будет выглядеть совершенно одинаково в обоих процессах.  Наша библиотека, в свою очередь, не должна ссылаться ни на какие библиотеки, которые не подписаны Microsoft. Но это не проблема - нам нужны две с половиной библиотеки, и они подписаны.  Давайте посмотрим и разберём код загрузчика - он не очень сложный, но длинный. Я убрал всю обработку ошибок для краткости.  Если отладка загрузки DLL через LoadLibrary была болью, то отлаживать вот это вот - 10/10 боли. Ни один дебаггер не понимает, что этот код - DLL, и не маппит проанализированную DLL с сырцами/PDB на код в процессе. Поэтому отладка без анализа. Приходится параллельно сопоставлять отлаживаемый код и проанализированный.  Альтернатива отладчику - логирование. И здесь бы оно очень подошло, потому что отладчик - боль. Проблема в том, что логирование - тоже боль. Процесс аудио подсистемы chrome не имеет прав на запись файлов (даже в Temp) и на создание ключей реестра - это из того, что я проверил.  Этот процесс точно имеет доступ к CoreAudio, но мне сходу не приходит в голову, как выводить логи при помощи аудио девайсов. Изучая разные подсистемы, обнаружил, что мне дают создавать сокеты и подключаться к внешним ресурсам. Бинго, пишем логгер, который льёт данные в localhost:7777 и слушаем его через nc -kl 7777. Но это не главное. Главное - это работает! Осталось всего ничего - находить процесс хрома и внедряться в него. Это сделано при помощи ETW логов, которые, в частности, сообщают о создании процесса. Для них есть библиотека krabs. И отвратительная документация. Подмена GetPosition для всех аудиоустройств начинает мешать, когда Bluetooth наушники отключаются, и задержка пропадает. Опережение звука - куда большая проблема, чем запаздывание, и мы не хотим вручную каждый раз менять задержку. Поэтому нужно бы узнавать, к какому аудио-девайсу относится данный IAudioClock, и настраивать задержку соответственно.  Это приводит к двум проблемам: Нужна программа, настраивающая задержки аудиоустройств Загруженная DLL должна знать, какому устройству принадлежит IAudioClock Если первая проблема решается довольно просто (см. код здесь), то вторая оказалась крепким орешком. СамIAudioClock не предоставляет ровно никаких способов достать из негоIMMDevice (у которого есть GetId) или самid. Есть два способа решения этой проблемы. Это один из возможных вариантов сопоставления IAudioClock -> IMMDevice. Можно просто перехватить все вызовы создания IMMDevice -> IAudioClient -> IAudioClock, и построить внутренние соответствия между ними. Это, однако, приводит к ряду проблем. Во-первых, становится необходимо перехватить гораздо больше функций (IMMDevice::Activate, IAudioClient::GetService, Release для всех трёх), и приходится отслеживать создание и удаление объектов, чтобы память не потекла.  Во-вторых, и это более важная проблема, нужно успеть внедрить DLL, пока аудио-устройства ещё не созданы. Практика показывает, что через ETW логи я не очень успеваю это делать. Можно было бы пропатчить родительский процесс хрома, чтобы он создавал процессы с CREATE_SUSPENDED, но это очень большой геморрой. И если приложение-инжектор упадёт, хром останется без звука.  Логика подсказывает, что если IAudioClock не будет знать, какому IAudioClient он принадлежит, он не сможет вычислять положение в потоке. Значит, где-то внутри IAudioClock содержится какая-то ссылка на IAudioClient. Если раскопать отладчиком, видно, что IAudioClient действительно сохраняется в IAudioClock: Аналогично, если посмотреть на IAudioClient, нам повезёт, и там сразу будет ссылка на Unicode строку с id девайса: Окей, чтобы хоть немножко повысить переносимость, давайте не будем фиксировать смещения, а поищем их в динамике: И дальше что-то такое: Ужас, конечно, но работает. В итоге я использовал оба подхода - если успели перехватить, записываем в словарь. Если не успели, используем подход с поиском клиента и id по смещениям. Код разбросан по этому файлу. После патчинга видео и аудио синхронизировались идеально: Так была исправлена неприятная проблема, и речь в Bluetooth наушниках теперь воспринимается отлично.  Работоспособность проверена только под последними версиями Win10 и Win11, на последнем же Chrome. Мой код. Injector для Chrome Ручное внедрение DLL (x86 версия, требует небольших доработок для x64) Krabs  SWE