EmuStudio-ZX

[breeze]

на win7 у меня delta либо 0 либо 480.

Лог в студию.

У меня ещё красивее значения: 6720, 0… 480, -7456, 52864, -55456, -1472

Windows 8 x64, встроенная Realtek HD Audio (ALC889)

http://paste.org.ru/?nklc06

[Titus]

10 мс - это то, с чем ты бороться не можешь, судя по всему. да и 10, и 20 мс - это вполне нормальное время задержки. я уверен, в слепом тесте на реале ты его (20 мс) не заметишь.


там не нужно море вычислений. я просимулировал получение позиции в буфере с дискретностью 480 сэмплов, взял 200 кадров. в итоге у меня получилось вот так.

Твоя теория далека от практики) Предлагаю тебе сделать рабочий макет)

---------- Post added at 17:34 ---------- Previous post was at 17:32 ----------

если это относилось к zx-mak, так там именно что он синхрился под vsync.

Т.е. каждый новый кадр спектрума совпадал с кадром развертки ПЦ?

Или же просто перед выводом нового кадра ожидался VBlank?

[psb]

Т.е. каждый новый кадр спектрума совпадал с кадром развертки ПЦ?

да вроде так. в этом режиме не надо было дополнительно указывать частоту прерываний спека. но это не 100%.

Твоя теория далека от практики) Предлагаю тебе сделать рабочий макет)

рабочий макет чего? эмулятора? больше заняться нечем.

ты утверждал, что при +-480 сэмплов нельзя точно определить частоту. я не поленился и проверил - считается ДОСТАТОЧНО точно. хочешь сказать, что я не прав - скажи почему.

[Titus]

ты утверждал, что при +-480 сэмплов нельзя точно определить частоту. я не поленился и проверил - считается ДОСТАТОЧНО точно. хочешь сказать, что я не прав - скажи почему.

Хорошо, опиши свой алгоритм определения частоты. По пунктам.

[psb]

1. скользящее среднее от буфера с разницами указателей на проигрывание между фреймами (тех самых, которые n*480).
2. скользящее среднее от 1.

быстро, дешево, точно.

[Titus]

1. скользящее среднее от буфера с разницами указателей на проигрывание между фреймами (тех самых, которые n*480).
2. скользящее среднее от 1.

быстро, дешево, точно.

Подробнее, этого мне не достаточно.

[psb]

каждый фрейм:

1. ищешь разницу указателей на проигрываемый кусок (у текущего и предыдущего фрейма), она будет 480 или 2*480 каждый раз.
2. кладешь в кольцевой буфер.
3. считаешь среднее от всего буфера, получаешь число.
4. кладешь это число во второй кольцевой буфер.
5. считаешь среднее от этого буфера, получаешь число.

вот это число и есть точное дробное значение кол-ва сэмплов за фрейм. фильтр можно подогнать под реальные условия, но главное, что из этих 480 и 2*480 он вполне выделяет точное число.

[breeze]

Кстати, Titus, обратил внимание на строчку:

Sound: 48000Hz, 16bit, 2 channels

А откуда берутся данные, что выбран режим 48000Hz. Тут много где рекомендуют, что бы не было глюков на встроенных звуковухах выставлять принудительно только 44000Hz, или это просто максимальные возможности указаны?

[psb]

А откуда берутся данные, что выбран режим 48000Hz.

скорее всего это дефолтные значения звуковухи (у меня есть такие в настройках). что правильнее ставить - зависит от своей звуковухи, ибо если она 48000, а ты поставишь 44100, то тоже будет "плохо".

[Titus]

Кстати, Titus, обратил внимание на строчку:



А откуда берутся данные, что выбран режим 48000Hz. Тут много где рекомендуют, что бы не было глюков на встроенных звуковухах выставлять принудительно только 44000Hz, или это просто максимальные возможности указаны?

Хм, вообще-то это я принудительно выставляю, в надежде, что это самый распространенный режим, и хорошее качество.

---------- Post added at 21:15 ---------- Previous post was at 20:59 ----------

каждый фрейм:

1. ищешь разницу указателей на проигрываемый кусок (у текущего и предыдущего фрейма), она будет 480 или 2*480 каждый раз.
2. кладешь в кольцевой буфер.
3. считаешь среднее от всего буфера, получаешь число.
4. кладешь это число во второй кольцевой буфер.
5. считаешь среднее от этого буфера, получаешь число.

У меня практически так и есть.

Вот смотри. При 48000Гц аудио и 75Гц видео в кадре умещается ровно 640 отсчетов. В начале каждого кадра я фиксирую позицию в аудиобуфере и вычисляю, сколько проигралось отсчетов. Обычно это 640 +- 2..5. Если разброс укладывается в необходимый коридор, то я добавляю длину проигранного буфера в кольцевой буфер статистики, если же нет, то отбраковываю и в статистике не учитываю. При длине кольцевого буфера 128 позиций, колебания +-2..5 уезжают в облась сотых долей отсчета, что позволяет ими пренебречь. В течение каждого кадра так же проверяется, отстаем мы от прогнозируемой текущей длины буфера (допустим, равной 640.01356) или же опережаем. Если отстаем то корректируем число отсчетов в кадре на +0.01, если опережаем, то наоборот, соответственно. И каждый кадр натягиваем звук на это дробное текущее число отсчетов в кадре. Если в случае экстренных тормозов Винды потеряли кадр, или же по каким-то причинам прогнозируемое число отсчетов отстало или уехало более, чем на пол-кадра (320 отсчетов), то все параметры обнуляются и указатели выставляются на 0 (тут будет склейка звука).

Теперь, что получается при биении +480? Да ничего не получается. Во-первых надо делать огромный пребуферинг, не в пол-кадра, а гораздо больше. Это означает, что звук уже будет заметно отставать от видео.
Во-вторых, колебания длины буфера будут в 100 раз больше, что для меня ну совсем неприемлимо.