last post from Retro-Nerd at the
Hallo,
habe das Thema jetzt erst hier entdeckt!
Genau das gleiche Problem habe ich auch mit dem Krächzen des Soundes, ich habe die neueste Dev Build installiert, aber auch ein paar Versionen von davor probiert.
Mit welcher Version habt ihr denn die Soundprobleme nun behoben?
P.S.: Kann man sich denn die Geschwindigkeit des Emulators im Vollbild irgendwie anzeigen lassen???
hau mal den groepaz an
Das Problem lag hier bei 50Hz+reSID, dann gibt es Soundkratzen und einen Einbruch in der Framerate (deutlich unter 50). Kann man auch im Fenstermodus sehen (wenn der in 50Hz läuft). Nur FastSID behebt es in 50Hz. In 60Hz gab es keine Probleme, nur das es dann natürlich stark ruckelt.
hau mal den groepaz an
Der sagt sinngemäß (Gedächtniszitat) "Shice reSID, macht nix als Ärger, fliegt bei nächster Version von VICE raus" 
Oder vorerst zu Micro64 wechseln. Dort gibt es diese Probleme überhaupt nicht.
Wenn sein Rechner schon bei VICE überfordert ist, dann braucht er Micro64 gar nicht erst runterladen.
Nochmals Micro64 läuft super, der Rechner ist nicht überfordert 
Es sei denn, man benötigt wirklich eine GTX aus der 800 Reihe, die habe ich noch nicht drin. Ganz ehrlich: Meine Freundin lässt den Vice auf ihrem Laptop laufen, und das ist so ein typischer Mädels Laptop, von vor 4 Jahren gekauft. Und dort läuft der super Ich habe aber im anderen Beitrag schon eine provisorische Lösung geschrieben:
1. 1/1 Wiederholrate
2. 99% Geschwindigkeit
Kann auch bestätigen, dass WinVICE bei 50Hz anscheinend Probleme mit der Synchronisation hat und in Abständen kratzigen Sound produziert. Bei 60 Hz läuft der Sound sauber.
Ich hab nur einen alten Core2Duo/2,6GHz/Win7-64bit und es mit Soundblaster Audigy 2 ZS und Onboard Realtek, FastSID und ReSID probiert. Kratzer treten auch bei FastSID auf, nur seltener.
Micro64 läuft da definitiv perfekter bei 50Hz.
Im Vergleich laufen andere Emus, wie z.B. KEGAfusion und WinUAE, bei 50 Hz flawless & superbutterweich.
hau mal den groepaz an
Ist das nicht der Sauhund? Wenn ja, warum ist der hier unregistriert?
Ist das nicht der Sauhund? Wenn ja, warum ist der hier unregistriert?
War seine eigene Entscheidung. Frag "schumi" per PN. Oder in der Shoutbox.
sl FXXS
Das Problem ist, dass das DirectX9 "Present" den Thread blockiert bis zum VBLANC der Grafikkarte und ich es ums Verrecken nicht hinbekomme (auch mit unabhängigen Threads), das Rendern aus VICE heraus komplett zu entkoppeln vom "Present". Dasselbe Problem haben laut Tante Google auch sehr viele andere DirectX Entwickler weil wohl die Grafikkartentreiber z.B. das Flag "NOWAIT" nicht beachten. Vielleicht muss ich auch noch etwas trickreicher mit den sog. "Swapchains" hantieren. Wenn sich hier jemand mit entsprechenden Kenntnissen tummelt. Her damit!
Notlösung ist das Aktivieren der Option "Render to DX primary surface" (das deaktiviert das VSYNC, was natürlich zu tearing führt) oder das Vergrößern des Soundbuffers auf z.B. 300ms (was zwar das Krächzen vermeiden sollte aber zu einer entsprechenden Verzögerung des Sounds führt).
Mit PresentationInterval in D3DPRESENT_PARAMETERS hast du vermutlich schon experimentiert? Normalerweise sollte der Wert D3DPRESENT_INTERVAL_IMMEDIATE ohne VSync sein, und 0 mit VSync.
Mit PresentationInterval in D3DPRESENT_PARAMETERS hast du vermutlich schon experimentiert? Normalerweise sollte der Wert D3DPRESENT_INTERVAL_IMMEDIATE ohne VSync sein, und 0 mit VSync.
Das ist genau das Flag, welches mit der VICE-Option "Render to primary surface" gesetzt wird. Bedeutet aber eben tearing.
Was genau ist denn das Problem, wenn Present blockiert? Sound sollte doch sowieso immer in einem eigenen Thread laufen.
Oder ist das Problem da, dass die Simulation (wenn die im Haupthread liegt) quasi mitgeblockt wird?
Oder ist das Problem da, dass die Simulation (wenn die im Haupthread liegt) quasi mitgeblockt wird?
Genau das ist das Problem. Der Hauptthread füttert sowohl den Videobuffer (rendert in ein "OffscreenSurface") als auch den Soundbuffer. Und an das Füttern des Video-Buffers folgt das Present. Und wenn das hängt, läuft der Soundbuffer leer.
Und selbst wenn ich für das Present einen eigenen Thread verwende, blockiert dieser irgendwie indirekt auch das OffscreenSurface (der ist ja Quelle für das Present), so dass auch hier wieder das Rendern des Hauptthreads in das OffscreenSurface blockiert wird, weil dieser noch nicht vom Present verarbeitet wurde.
Was ich bisher nicht hinbekommen habe ist, das Rendern in das OffscreenSurface vollkommen zu entkoppeln vom Present (das Present müsste dann wahrscheinlich hin und wieder einen Puffer auslassen, weil dieser vom Hauptthread gerade erneut gerendert wird). Eigentlich müsste man das mit geeigneter Verwendung von "SwapChains" (alles Begriffe, die in der DirectX Doku zu finden sind) hinbekommen, aber ich bin leider kein DirectX Profi und der DX-Treiber in VICE war meine erste und bisher einzige Programmierung mit dieser API.
Wenn du nicht explizit multithreaded beim Erstellen des Devices angegeben hast, sollte man das nur aus dem einen Thread ansprechen. Grade bei älteren DXen sollte man das generell, multithreaded kommt erst richtig mit neueren Versionen.
Du kannst natürlich mit D3DPRESENT_INTERVAL_IMMEDIATE arbeiten und das VSyncen manuell erledigen. Wobei das im Fenstermodus nur ganz grob geht und daher trotzdem Tearing bleibt.
SwapChains habe ich selbst nie benutzt, aber das klingt, als könnte es in Verbindung mit D3DSWAPEFFECT_FLIP und mindestens 2 Buffer helfen: https://msdn.microsoft.com/en-…op/bb173393(v=vs.85).aspx
Das dieses Problem eh keinen der Vice Entwickler am Herzen liegt: Es gibt mittlerweile eine Lösung für Windows. Einfach RetroArch samt vice_x64_libretro.dll nutzen. Da werden andere Video/Audio Renderer genutzt. Läuft in 50Hz alles bei 100% Speed ruckelfrei. Auch meine reSID Probleme gibt es da nicht. Klar, die Bedienung von RetroArch mag nicht jedem gefallen. Und man kann derzeit nicht so viel konfigurieren. Aber simpel ein D64 oder CRT direkt laden ist kein Problem.
Es gäbe jetzt nicht zufällig umgekehrt Mittel und Wege, diese anderen Renderer optional in Vice reinzuhäkeln, oder?
Es gäbe jetzt nicht zufällig umgekehrt Mittel und Wege, diese anderen Renderer optional in Vice reinzuhäkeln, oder?
Dazu müsstest du jemanden auftreiben, der sich gut genug mit Windows-Programmierung auskennt, um den Code aus Retroarch zu nehmen und in VICE einzubauen.
Da hängt wohl sicher noch mehr dran als die nur Renderer. RetroArch hat eine Dynamic Rate Control, neben dem Vsync auch eine Audio Sync Option.
