DirectShow, в частности Rate Matching, временные метки и DirectSound Audio Renderer

Может ли кто-нибудь дать мне краткое объяснение того, как и почему DirectShow DirectSound Audio Renderer будет регулировать скорость, когда у меня есть собственный фильтр захвата, который не показывает часы?

Я вообще не могу понять этого. Когда начинается звук, я назначаю rtStart равным нулю плюс длительность семпла (numbytes / m_wfx.nAvgBytesPerSec). Тогда время начала следующего сэмпла совпадает с временем начала предыдущего сэмпла и так далее ....

Некоторое время спустя фильтр захвата определяет, что Directshow слишком быстро потребляет сэмплы, и пытается установить временную метку некоторого времени в будущем, которую средство рендеринга звука полностью игнорирует. В качестве теста я могу внезапно сказать образцу, что он не должен отображаться до 20 секунд в будущем (StreamTime () + UNITS), и снова средство визуализации просто игнорирует его. Однако Null Audio Renderer делает то, что ему говорят, и весь график замирает на 20 секунд, что является ожидаемым поведением.

Вкратце, я хочу, чтобы звуковой рендерер использовал либо мои часы захвата (или свои собственные, или графические, мне все равно), но мне нужно, чтобы они подчинялись временным меткам, которые я ему отправляю. Что мне нужно, так это сжимать или растягивать сэмплы, пусть даже очень тонко, чтобы компенсировать разницу в скоростях между DSound и встречным потоком (скорость которых я не могу контролировать).


person r webby    schedule 31.10.2014    source источник


Ответы (1)


MSDN объясняет технологию здесь: Живые исходники, я полагаю, вам знакома эта тема документации.

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

Кажется, что ваш фильтр захватывает в реальном времени (фильтр захвата, а затем вы упоминаете, что не контролируете скорость данных, которые вы получаете извне). Таким образом, вам нужно убедиться, что ваш фильтр захвата распознается как источник в реальном времени, а затем вы выбираете часы для воспроизведения и общий режим работы. Я полагаю, вы хотите услышать описанное поведение AM_PUSHSOURCECAPS_PRIVATE_CLOCK:

исходный фильтр использует частные часы для генерации отметок времени. В этом случае средство визуализации звука сопоставляет скорости с отметками времени.

Вот о чем вы пишете выше:

  • ваша отметка времени в соответствии с внешним источником
  • воспроизведение осуществляется с использованием часов аудиоустройства
  • аудио-рендерер сопоставляет скорость, чтобы соответствовать скорости

Чтобы увидеть, как именно происходит согласование скорости, вам нужно открыть страницы свойств аудио-рендерера, страницу Advanced:

Расширенная страница свойств

Данные в разделе «Информация о подчиненном» будут отображать детали согласования скорости (в моем примере соответствие 48000/48300). Данные также доступны программно через IAMAudioRendererStats::GetStatParam.

person Roman R.    schedule 01.11.2014
comment
Здравствуйте, Роман! Я действительно делаю AM_PUSHSOURCECAPS_PRIVATE_CLOCK и выставляю часы через QI. В статистике рендерера я замечаю, что подчиненная информация говорит Live Timestamp и просто сидит на (что, как я полагаю, является максимальной скоростью для 44100 sr: 44713. Таким образом, рендерер считает, что скорость слишком высока, и я не знаю, почему ! - person r webby; 01.11.2014
comment
Я не понял, какой эффект вы наблюдаете. Согласование скорости - которое вы предположительно считаете неправильным - заканчивается ли оно опустошением буфера воспроизведения? перерасход? Проверка расписания выборки на 20 секунд в будущем понятна: когда включено согласование скорости и он обрабатывает источник как живой, тогда не может быть данных из будущего, только живые данные. Таким образом, эта отметка времени игнорируется ИЛИ сбрасывает внутренние счетчики совпадений. - person Roman R.; 01.11.2014
comment
Оказывается, это я: я пытался быть слишком умным: заполнял поток сэмплов, когда поток начинался, с тишиной - конечно, тогда каждый сэмпл после этого запаздывает, и поэтому рендерер выходит из строя (что оказывается около 44370). Это один из тех случаев, когда простой вопрос помог мне более четко понять, что я делаю! Это большая проблема для магазина из одного человека; не с кем озвучивать проблемы! - person r webby; 01.11.2014