Van!
Csetlik-botlik...
(Ez valami teljesítményprobléma lenne...? Az általam emlegetett C64 emu hangja pláne borzalmas, van is kb. 5FPS... )
Nem teljesitmenyproblema, hanem az, hogy meg nem talaltam ki hogy tartom az audio puffer olvasasat (amit a WebAudio API onaudioprocess callback-je "olvas") szinkronban azzal, hogy az emulator meg feltolti az emulalt Dave regiszterei alapjan a hangmintaval (ui a WebAudio mint kb minden audio specifikus API nem teszi lehetove hogy egyesevel add oda a hangmintakat, hanem egy buffert var el, pl mondjuk 1024 sample lejatszasa utan keri a kovetkezo 1024-et), igy folyamatosan alul/felulcsordul szegeny. Nyilvan, ha ez meg is lenne, nem megfelelo JavaScript teljesitmeny eseten ugyanugy rossz lenne (max mas jellegu hang hiba lenne, pl kihagy neha a hang), a kulonbseg az, hogy most egy atomeromu-PC-n is ilyen
Ezt amugy nem olyan egyszeru megoldani, a WebAudio API pl azt mondja hogy sampling rate 44100Hz. Az emulacio idozitese alapjan _elvileg_ beloheto, hogy hany CPU/nick/stb ciklus jut egy hangmintara. Azonban ez sose lesz stabil egeszen pontosan es elobb-utobb elmaszik, plane, mivel tokeletes idozitest egy-egy frame emulacioja utan nem is tud a JavaScript, mar 1-2 msec sem mindig jon ossze pontosan.
Amugy teljesitmenyproblemat az JSEP eseten onnan lehet eszrevenni, hogy nezed a "timeout is ..." utani szamokat. Ha a perjel elotti 1-es erteket vesz fel (nem "turbo" modban, mert akkor mindig annyi ....), akkor keves neki a gep/js/browser stb performanciaban, foleg ha tartosan ott maszkal. Minnel kozelebb van a ket szam, annal jobb. Ha 1-esen van az elso szam, az azt jelenti, hogy az emulacio mar lassabb mint real time. Valojaban persze ilyenkor nulla vagy negativ lenne, dehat negativ varakozasi idot nehez csinalni
nullat meg nem celszeru mert akkor a browsert total megakasztod, es sajat magara sem lesz ideje. Ezert van 1-ben limitalva.