Аппаратная эмуляция GS/TFM/AY

[ZEK]

думаю разницы никто не заметит

wait в 20мс кто угодно заметит

[Black_Cat]

wait в 20мс кто угодно заметит

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

[ZEK]

Black_Cat
Ну ты издеваешся??
К примеру мы находмисмся в 1/3 части кадра, и спрашиваем у ГС какой щас трек(и как они там называются) воспроизводится, что бы ГС могла на это ответить ей нада проэмулить 1/3 кадра, а она не будет этого делать пока не наберется фрейм

Добавлено через 1 минуту
Vitamin, я че думаю, последняя нить рассуждений не совсем в тему??

[Black_Cat]

что бы ГС могла на это ответить ей нада проэмулить 1/3 кадра, а она не будет этого делать пока не наберется фрейм

вот здесь не понял на счёт проэмулить 1/3 кадра и ждать до полного фрейма - эт зачем?

[ZXMAK]

Латентность будет смертельно большая (в смысле для качественой работы), к тому же эмули работают не в реалтайме (на широком круге ОС недостижимо) а порциями по 20мс, то есть пока не набьеш буфер в 20мс длиной для звука его на звуковуку не посылают

на pc звук с реакцией 20 мс это практически недостижимо, для этого нужно dsp или чтонить аппаратное использовать. Обычно в win хорошая реакция звука 50-100 мс, задержку больше 100-150 уже можно заметить, если очень внимательно следить. 200-500 мс уже можно заметить на контрастных фрагментах (например щелчек с одновременной вспышкой на видео).
Да и DirectX сам по себе, незаметно для софта делает задержки для звука и видео, он старается держать один-два кадра про запас... Но программно это не заметишь...

в Win XP минимальный time slice у менеджера потоков в нормальном режиме равен 130 ms (!), не путать с quantum (10 ms). Поэтому реально можно расчитывать на работоспособность кода раз в 130 мс... В наиболее благоприятном случае (в системе все остальные потоки простаивают) можно расчитывать на 10 мс, что в реальности бывает не так уж и часто и уж точно не стабильно... quantum конечно можно уменьшить до 1 мс (timeBeginPeriod), немного увеличив время реакции когда (только для благоприятных условий) но это плохо отразится на производительности многопоточных программ...

[Black_Cat]

но это плохо отразится на производительности многопоточных программ...

полагаю что при таком использовании РС никакой другой софт исполняться не будет, но лаги в 100-150 мс эт конечно смертельно.. Тоды остаётся только ДОС, хоть это конечно и весьма неудобно, но в конце концов думаю такой плеер можно загрузить и с дискеты..
Александр, на счёт ДОСа по задержкам можете что сказать?

[Vladimir Kladov]

Вообще-то под виндой есть приоритет real time. Если программа не занимается клавиатурой или мышью, ей можно дать этот самый приоритет. Разумеется, программа должна хорошо работать и не циклить и не виснуть в ожиданиях, иначе восстановить работоспособность системы удастся только ресетом писюка. В случае двухъядерника будучи запущенной в реальном приоритете задаче сожрёт только один процессор, и в принципе, на ПЦ ещё что-то можно будет поделать. С учётом тенденции полного перехода на многоядерники такой режим вполне возможен. И в этом случае разговоры о латентности не нужны, реакция получается достаточно быстрая (в пределах 1 мс). На ГС хватит, и на флопарь какой-нибудь тоже. Что касается АY и других звуковых устройств, не требующих обратной связи, ситуация ещё проще, там хватит и одноядерника и работы в повышенном (но не рилтайм) приоритете.

[ZXMAK]

Вообще-то под виндой есть приоритет real time. Если программа не занимается клавиатурой или мышью, ей можно дать этот самый приоритет.

приоритет ничего не даст, т.к. временные характеристики не меняет. Для каждого приоритета просто отдельные очереди. И пока очередь потоков с высоким приоритетом не пуста, потоки с более низким приоритетом процессорное время не получат. На время переключения потоков это никак не влияет

Добавлено через 4 минуты

реакция получается достаточно быстрая (в пределах 1 мс).

реакция 1 мс на Windows в нормальном режиме невозможна, т.к. quantum = 10 мс, да еще и поток в системе явно не один крутится

Если уменьшить quantum до 1 мс (timeBeginPeriod, DX вроде сам это делает при эксклюзивном захвате видеоадаптера), то рекация в 1 мс будет очень и очень нестабильной, плюс проблемы с многопоточностью

Добавлено через 10 минут

на счёт ДОСа по задержкам можете что сказать?

дык дос онже однопоточный
Да, чтобы получить 20 мс, сама звуковая карта должна иметь задержку не превышающую это значение (X-Fi вроде этому условию удовлетворяют)

[Black_Cat]

дык дос онже однопоточный

ДОС, эт конечно вариант запасной, но если чисто теоретически, то зачем нам для эмуля звуковых устройств больше?

Добавлено через 7 минут

X-Fi вроде этому условию удовлетворяют

что за зверь? под ДОСом боюсь что ни на что другое кроме SBPro ориентироваться не получится

[Vladimir Kladov]

приоритет ничего не даст, т.к. временные характеристики не меняет.

Да неужели? Мы говорим о разных вещах? Какие такие характеристики не мяет рилтайм? А вы пробовали ЧТО-НИБУДЬ КОГДА-НИБУДЬ запустить в РИЛ-ТАЙМ приоритете? А вы попробуйте, на какой-нибудь безобидной игрушке. Если у вас система намертво не зависнет после этого, то вы получите представление о том, что такое рил-тайм и однопользовательский режим в винде. Понятие время реакции исчезает. Правда, ничего больше и не работает, даже не пытается.