Общий подход к эмуляции биперного звука

[CityAceE]

Все семплы с таймера не пишутся в буфер, это был бы очень большой буфер, а пропускаются через ресемплер

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

Мне в его написании очень помогли ivagor

Иван прям везде успевает Я когда упёрся в этот вопрос, тоже первый, о ком я подумал был как раз Иван

кол-во единиц * 255 / 45
Или тут какие-то подводные камни есть?

Опять же, такой вариант первым пришёл мне в голову. Но я не уверен, что это будет работать так, как должно. Вот я и хотел узнать, есть ли какие-то подводные камни?

Я сейчас проиллюстрирую примером с идеальными условиями из "Ну, погоди!":

Вот с такими значениями инициализируется звуковой буфер:

# Инициализация звукового буфера, должна быть раньше всех инициализаций!
# pygame.mixer.init(frequency=16384, size=8, channels=1, buffer=1024)
pygame.mixer.init(16384, 8, 1, 1024)

А вот так буфер заполняется:

sound = cpu.exec_op_code()
buffer[i] = sound * 255

То есть после исполнения каждой команды процессора снимается значение порта, отвечающего за звук. Если там 0, то в буфер пишется 0, а если единица, то 255. И потом, по достижении конца буфера (1 кб), выводится 8-битный одноканальный звук с частотой дискретизации 16 кГц.

Будет ли корректным результат, если я сложу 45 значений порта (единицы и нули), умножу их на 255 и разделю на 45, откинув дробную часть? Видимо, пока не проведу эксперимент, не узнаю. Однако для этого придётся поменять логику ядра эмулятора. Сейчас в эмуляторе виртуальный процессор тактируется экраном: экран рисуется 50 раз в секунду, а между выводами экрана отрабатывается 2 000 000 Гц / 50 = 40 000 тактов и ждёт отрисовки следующего экрана.

[Advertiser]