EmuStudio-ZX

[Titus]

похоже, Titus, не на ту лошадку ты поставил.
как показывает мой сонар, в составе винды есть wdm/ks и mme, интересно что пользуешь ты. скорее всего wdm.
посмотри в сторону альтернативных аудиобиблиотек в составе эмуля, может быть alsa...

То, что не на ту - однозначно.
Просто оба моих компа (в одном Audigy в другом SB Live) прекрасно давали информацию о позиции во вторичном буфере, и я на этом успокоился.

---------- Post added at 12:06 ---------- Previous post was at 12:02 ----------

Titus, а все-таки объясни мне глупому, пожалуйста- нафига нужная такая точность определения "текущей позиции эмуляции", если при этом вывести кадр "вне очереди" все равно нельзя? И откуда информация, что тактирование звуковухи более точное, чем тактирование кадровой развертки?

Любое тактирование, что звуковухи, что видеокарты точное. Только соотношение этих тактовых источников не известно, и не может быть известно. Только примерно можно узнать.
Следовательно, привязаться можно к одному из этих источников (звук или видео), а информацию для второго подгонять в зависимости от текущих измерений соотношений их тактовых частот. Тактирование от аудио мне не подходит, так сделано во всех эмулях, ибо тогда нет никакой гарантии плавности видео (когда кадр эмуируемой системы всегда равен кадру ПЦ). Я выбрал тактирование от видео. В этом случае видео будет абсолютно плавное, а скорость аудио надо измерять и подгонять под измеренное.

[Vitamin]

Тактирование от аудио мне не подходит, так сделано во всех эмулях

Не во всех. Где-то встречал от RTC.

В этом случае видео будет абсолютно плавное, а скорость аудио надо измерять и подгонять под измеренное.

Все равно нужны какие-то абсолютные точки во времени.

[Titus]

Все равно нужны какие-то абсолютные точки во времени.

Абсолютные точки берутся от кадровой развертки)

---------- Post added at 12:21 ---------- Previous post was at 12:20 ----------

Не во всех. Где-то встречал от RTC.

Это еще более плохой случай. В нем ни видео, ни музыка не будут 'плавными'.

[Vitamin]

Абсолютные точки берутся от кадровой развертки)

Т.е. частота кадровой развертки стабильна и точно известна?

Это еще более плохой случай. В нем ни видео, ни музыка не будут 'плавными'.

Ну смотря что за клоки. Если счетчик команд, то да, будет фигня. А если фиксированный высокочастотный счетчик шедулера, то вполне.

[Titus]

Т.е. частота кадровой развертки стабильна и точно известна?

Ну смотря что за клоки. Если счетчик команд, то да, будет фигня. А если фиксированный высокочастотный счетчик шедулера, то вполне.

Стабильна - да. Точно известна в пределах долей процента, чего абсолютно достаточно для нужд эмуляции.

Где у нас в винде ты видел стандартный счетчик с разрешением меньше 1мс?

[Vitamin]

Стабильна - да. Точно известна в пределах долей процента, чего абсолютно достаточно для нужд эмуляции.

Ну а раз звук плавает, то чем щелчки выпадающих семплов лучше выпадающих кадров?

Где у нас в винде ты видел стандартный счетчик с разрешением меньше 1мс?

Да я и насчет нестандартного не уверен

[Advertiser]

[Titus]

Ну а раз звук плавает, то чем щелчки выпадающих семплов лучше выпадающих кадров?

Ничего не выпадает. Звук плавает по частоте не более, чем на сотые доли процента. на слух это абсолютно не заметно. Никаких щелчков и прочего при этом нет. На практике долго гонял на своем компе, на котором звуковуха позволяет точно контролировать вторичный аудиобуфер - все идеально.

[psb]

Тактирование от аудио мне не подходит, так сделано во всех эмулях

ну не во всех. старый zx-mak умел синхриться от кадровой, 60 гц тоже показывал плавно. унреал, емнип, синхрится НЕ по звуку.

и все же, еще раз для отстающих, Titus, вот поясни такой момент. допустим, разрешение по позиции в буфере - 480 сэмплов. при 44100 гц - это 10 мс, т.е. полфрейма.
ты считаешь, сколько надо сэмплов за фрейм, примерно 882. кладешь в буфер 882+480 (это запас, например от нового фрейма). через фрейм у тебя указатель будет +480 или +2*480. если ты соберешь разницу за кучу фреймов, отфильтруешь, ты узнаешь реальную частоту потребления сэмплов звуковухой (дробное число).

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

прежде чем говорить нет - напиши симулятор.

[Titus]

ну не во всех. старый zx-mak умел синхриться от кадровой, 60 гц тоже показывал плавно. унреал, емнип, синхрится НЕ по звуку.

и все же, еще раз для отстающих, Titus, вот поясни такой момент. допустим, разрешение по позиции в буфере - 480 сэмплов. при 44100 гц - это 10 мс, т.е. полфрейма.
ты считаешь, сколько надо сэмплов за фрейм, примерно 882. кладешь в буфер 882+480 (это запас, например от нового фрейма). через фрейм у тебя указатель будет +480 или +2*480. если ты соберешь разницу за кучу фреймов, отфильтруешь, ты узнаешь реальную частоту потребления сэмплов звуковухой (дробное число).

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

прежде чем говорить нет - напиши симулятор.

Надо уточнить, синхронизация с началом кадра и синхронизация относительно кадровой развертки - вовсе не одно и то же.

Вот все, как ты рассказываешь, дробное число отсчетов в кадре, но для его получения такой грубой дискретности, как 480 отсчетов - более, чем недостаточно. Я над этим экспериментировал достаточно долго, и вычислений делал море.

Сейчас вычисление дробного количества отсчетов в кадре идет по статистике аж 128 последних кадров. Тогда этого достаточно для высокоточной скорости аудио.

[psb]

Надо уточнить, синхронизация с началом кадра и синхронизация относительно кадровой развертки - вовсе не одно и то же.

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

Вот все, как ты рассказываешь, дробное число отсчетов в кадре, но для его получения такой грубой дискретности, как 480 отсчетов - более, чем недостаточно. Я над этим экспериментировал достаточно долго, и вычислений делал море.

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

881.292
881.292
881.292
881.292
881.292
881.28
881.292
881.292
881.292
881.292
881.292
881.28
881.292
881.292
881.292
881.292
881.292
881.28
881.292
881.292
881.292
881.292
881.292
881.28
881.292
881.292
881.292
881.292
881.292
881.28
881.292
881.292
881.292
881.292
881.292
881.28
881.292
881.292
881.292

это для шумящего кол-ва отсчетов на кадр, которые равны 882+рандом(-5,3). КУДА ЕЩЕ ТОЧНЕЕ???

при этом, ПИ-регулятор держит заполнение буфера (эмулируемое) сносно. колбасит, но не сильно.

---------- Post added at 18:18 ---------- Previous post was at 18:16 ----------

Надо уточнить, синхронизация с началом кадра и синхронизация относительно кадровой развертки - вовсе не одно и то же.

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