Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: GM ASIO ALPHA 0.171  (Read 48171 times)

0 Members and 1 Guest are viewing this topic.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #160 on: June 28, 2015, 04:31:50 pm »
When adding Framedelay 8, we're "postponing" the sample generation and copy to audio buffer by almost a full frame.

at earliest audio can begin playing at the end of the first frame.

Not really.

Ideally, an emulator running on a reasonably powerful cpu is most of its time waiting for vsync, because the time it takes to actually emulate a frame is close to zero. What we do with frame delay is to wait until the very last moment to emulate the frame so we can read the must up-to-date input. Perfection would be to be able to emulate the whole frame during the vertical retrace period, although we're not there yet. We need to start the emulation a bit before vertical retrace (frame_delay 8) so we don't miss the retrace. So actually "first frame" starts after having waited already (fd 8) and the frame contents (audio and video) are presented almost immediately after the actual emulation.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #161 on: June 28, 2015, 04:52:36 pm »
When adding Framedelay 8, we're "postponing" the sample generation and copy to audio buffer by almost a full frame.

at earliest audio can begin playing at the end of the first frame.

Not really.

Ideally, an emulator running on a reasonably powerful cpu is most of its time waiting for vsync, because the time it takes to actually emulate a frame is close to zero. What we do with frame delay is to wait until the very last moment to emulate the frame so we can read the must up-to-date input. Perfection would be to be able to emulate the whole frame during the vertical retrace period, although we're not there yet. We need to start the emulation a bit before vertical retrace (frame_delay 8) so we don't miss the retrace. So actually "first frame" starts after having waited already (fd 8) and the frame contents (audio and video) are presented almost immediately after the actual emulation.

Thanks for clarifying this. My fd_theory picture proved to be correct. :)

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #162 on: June 28, 2015, 05:21:39 pm »
Guys, thanks for thinking with me.

But I'm not sure if you're fully appreciating my point.

Of course for video you are right, but why would audio need to wait for vertical sync to start playing?

My comment was that it actually doesn't need to wait 16.7ms (60hz) for vsync, but can start as soon as audio data is ready.

For example Commodore Amiga is known to use different sync methods (besides vsync) for audio replay routines, such as cpu or other system timers (cia).

So why should audio need to wait until the end of raster to start playing? If I'm syncing to an internal clock, like is possible with Amiga, couldn't it be that audio starts playing much earlier than vblank, for example after the first few milliseconds (or whenever audio data is ready) into a frame?

Hope I'm making myself clearer now!


Edit: to clarify further, my hypothesis for above example would be:
- Real Commodore Amiga: generates samples at the beginning of the first frame, starts playing sound immediately, does not wait for vsync

VS

- MAME emulated Commodore Amiga: generates samples at end of frame (framedelay 8 ), waits for vsync, then starts playing audio

Conclusion: MAME emulated Commodore Amiga would lag almost a frame regarding when audio replay is started versus the real Amiga.
« Last Edit: June 28, 2015, 05:33:31 pm by Dr.Venom »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #163 on: June 28, 2015, 05:24:59 pm »
Of course for video you are right, but why would audio need to wait for vertical sync to start playing?

Audio doesn't wait, it starts playing immediately. It's the emulation of the audio hardware what waits.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #164 on: June 28, 2015, 05:32:44 pm »
Of course for video you are right, but why would audio need to wait for vertical sync to start playing?

Audio doesn't wait, it starts playing immediately. It's the emulation of the audio hardware what waits.

So I'm right into thinking that audio replay in the emulation may start almost a frame later than the real hardware?

Please see also my clarification in previous post. 

Edit: Calamity, I'm talking about the very first frame, not just any frame.  So that would be the blue period in intealls picture where a real machine (say Amiga) starts playing audio already. Someone explain to me whether that is possible or not for the very first frame of a program that is executed on a real Amiga.

Maybe I'm missing the point how this is executed on real Commodore Amiga hardware?
« Last Edit: June 28, 2015, 05:43:01 pm by Dr.Venom »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #165 on: June 28, 2015, 05:42:32 pm »
So I'm right into thinking that audio replay in the emulation may start almost a frame later than the real hardware?

No, that's wrong. That's what I tried to explain  :)

The error is in how you're using the concept of "first frame". The "first frame" in the emulation starts *after* the first vertical retrace happens, not before. At that point, the frame that just got emulated an instant before vertical retrace is presented, and represents the point where the Amiga is turned on.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #166 on: June 28, 2015, 05:44:40 pm »
But my concept of the very first frame is intealls picture. The blue part is the part *before* vsync :)

Edit: forget for a second the whole emulation part. Emulation is out of the picture. We're only talking about real hardware now.

In intealls picture the very first frame (on top of his picture) is starting with the blue part. This is where stuff is already generated in the computer. Is it possible that real hardware starts playing audio there already?
« Last Edit: June 28, 2015, 05:49:26 pm by Dr.Venom »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #167 on: June 28, 2015, 05:55:56 pm »
Real hardware will start playing audio during the first frame.

But that first frame, in the emulation, corresponds with the second iteration of the loop (second column in intealls' drawing).

The first iteration of the loop is required to synchronize the emulator with the vertical retrace for the first time. Emulation has not started yet.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #168 on: June 28, 2015, 05:57:02 pm »
But my concept of the very first frame is intealls picture. The blue part is the part *before* vsync :)

Edit: forget for a second the whole emulation part. Emulation is out of the picture. We're only talking about real hardware now.

In intealls picture the very first frame (on top of his picture) is starting with the blue part. This is where stuff is already generated in the computer. Is it possible that real hardware starts playing audio there already?

The very first frame is emulated just like any other frame. Think of the emulation as a slight delay.

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #169 on: June 29, 2015, 06:46:25 am »
Hi guys, thanks for your thoughts on this, I understand what you're saying on real hardware versus emulation.

It doesn't close the topic for me yet though. There's still itching something about there being added audio latency between fd 0 and  fd 8 in emulation context. Please see attached picture, outlining why in my view framedelay adds to audio latency.**

First let's see if we agree on this case. If we do, it may give an interesting new insight (at least for me) on the case of real hardware vs emulation fd 8 vs emulation fd 0.



**Note that this considers the case from an optimal emulator standpoint, MAME may or may not (yet) work this way, I don't know. I guess you are able to tell.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #170 on: June 29, 2015, 07:47:44 am »
Your drawing is correct. Your conclusion is not.

With fd 8, the actual concept of emulation starts at instant t-1, not t-0, that's the point. It starts with video and audio perfectly synchronized. The first interval (t0-t1) is not part of the emulation yet, it's just used to get synchronized with the retrace.

Your scenario with fd 0 shows the typical case in emulation. It doesn't inply lower audio latency but higher video latency (audio/video mismatch in any case).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #171 on: June 29, 2015, 08:40:48 am »
This is puzzling. How can the picture be correct but the conclusion not?

In both cases you -need- to synchronize with the PC retrace before you can start to do anything. That's the first blue dot in the picture.  I don't see how you magically shift the emulation with framedelay 8 before that blue dot, but with framedelay 0 you do not? The starting point for both approaches must be the same, and that is the blue dot in the picture. This is the really puzzling part. You keep insisting that fd 8 somehow is started before that vsync, but I really don't understand why it then can be the same for fd0? It seems like you're creating an apple and a pear from two apples.

Could you possibly enlighten your thinking a bit with some illustration? 


Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #172 on: June 29, 2015, 09:47:40 am »
You keep insisting that fd 8 somehow is started before that vsync

No, I'm not saying that at all.

Dr., I'm already doing my best to try to explain this, not sure if I can reformulate my explanation any better.

My point is that in your drawing, in the fd 8 part, you have to put the origin of your reference system at t-1. The part on the left of t-1 doesn't belong to emulation, although we need it for implementation reasons. So for the latency discussion you should cover the part on the left with a piece of paper. It's meaningless to measure latency assuming t-0 as the origin of time, that's the point.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #173 on: June 29, 2015, 10:12:23 am »
Calamity, I know you're trying your best to explain, and I'm sure we will get on the same page.

I've created a new picture to try and shed more light on the matter (at least for myself), this time incorporating real hardware.

Please note that in the picture all three approaches, real Amiga, emu fd8 and emu fd0, are aligned to when the first scanline of the video display is starting (marked by the yellow boxes). This point in time is called "t0".

Note that there are now only "t-1" (t minus 1), "t0" and "t1".

On the right, there is a comparison between each approaches' first frame.  based on this I'm still holding the thought that it's only possible with framedelay 0, to match the "front running" of audio of the real Amiga, versus t0, the moment video display is started in all three approaches and how audio latency will be perceived.

See it as that we are physically aligning the video display of all three aproaches at moment t0, for recording purposes. That we take as starting point for drawing how frames are prepared in all three and at what point in time audio is started in all three approaches. 

Hope I'm not asking too much, but it will be of great help: Could you please load up attached picture in paint or something and scratch what needs to be changed to get clarity on all three approaches? Since a picture tells a thousand words, I think we'll quickly get on the same page again and save more discussion ;).

It would be great if we could work towards a final version of this picture, such that we can keep it for future reference.
« Last Edit: June 29, 2015, 10:27:46 am by Dr.Venom »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #174 on: June 29, 2015, 10:52:34 am »
Hopefully this clarifies my point.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #175 on: June 29, 2015, 12:13:01 pm »
Thanks Calamity for adding your changes. To be fair, I'm not sure if it helps clarify your point.

The problem (in my personal view) remains that you shift the very first frame emulation in fd0 (the yellow dot) by one vsync to the right. You're effectively starting the fd0 emulation one whole vsync later than the fd8 case, only then to come to the (obvious) conclusion that the fd0 case has one frame of lagging video (and audio).  That doesn't seem like the right logic to me.

It must be possible for you to keep the video display start for all three at the reference "t0" and still explain your view?

I have uploaded the spreadsheet on which the picture is based to google sheets. It can be accessed here: https://docs.google.com/spreadsheets/d/1839b76DcZa9G90xmN5TUHLtrDwOhtEoBzxZzcv3euPc/pubhtml. Maybe helpful (for anyone) to shed new light on this matter.


Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #176 on: June 29, 2015, 12:40:18 pm »
You're effectively starting the fd0 emulation one whole vsync later than the fd8 case

Not really.

If you see the drawing, the yellow square (the emulation) in fd 0 is just two squares to the right with respect to fd 8. Not a whole frame period. For the purpose of this explanation, you could assume the blue vsync square to have zero size, so the yellow squares would be shifted by one position only, with the black thick line representing the retrace in the middle. That's where they must be aligned for a proper comparison.

You are mistaking the start of emulation with the start of the emulator program.

Quote
only then to come to the (obvious) conclusion that the fd0 case has one frame of lagging video (and audio)

This is not the conclusion, it's the premise!!  :D
It is a fact! The reason why we implemented frame delay in the first place. And you were there!  :D


Quote
It must be possible for you to keep the video display start for all three at the reference "t0" and still explain your view?

Of course you can do that but it's fooling yourself. What you want to align is not the video display start, but the game logic (real and emulated). That's what I did in my modified drawing.
« Last Edit: June 29, 2015, 01:23:14 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #177 on: June 29, 2015, 01:55:42 pm »
Hey guys,

how about this one.

Let's assume for a second that we're emulating a system with _no_ input delay, and _no_ audio output delay. I think the closest actual thing in real-life would be a completely analog machine. The video still needs to be synchronized against the vertical refresh, but the audio system could theoretically be completely decoupled.

If we only poll for input changes once per video frame, we have a problem, since the system we try to emulate instantaneously responds to input, regardless of when it happens.

To emulate the system perfectly, we would have to poll the input at an infinite speed. I highly doubt that the majority of systems MAME emulates do anything remotely related to this, so the point is probably mute, and I'm certainly no expert on these matters.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #178 on: June 29, 2015, 02:04:45 pm »
If we only poll for input changes once per video frame, we have a problem, since the system we try to emulate instantaneously responds to input, regardless of when it happens.

We hold this debate long ago and concluded that this type of emulation ("frame-based" emulation) can only be "perfect" for games that poll input once per frame. If we could actually do scanline-based emulation (hsynced instead of vsynced) it should be possible to get closer to that. But that would probably mean rewriting all emulators, and serious implementation issues with video APIs that expect you to work with frames rather than scanlines.
« Last Edit: June 29, 2015, 02:06:49 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #179 on: June 29, 2015, 02:11:23 pm »
You're effectively starting the fd0 emulation one whole vsync later than the fd8 case

Not really.

But you are. From what I understand from your reasoning, the frame emulation in the case of fd0 falls *after* the vertical sync that you allow the fd8 case to catch. There's no grey area. Because of this the fd0 case has to wait for the next retrace to start displaying. There's your one frame of delay.

Quote
If you see the drawing, the yellow square (the emulation) in fd 0 is just two squares to the right with respect to fd 8. Not a whole frame period. For the purpose of this explanation, you could assume the blue vsync square to have zero size, so the yellow squares would be shifted by one position only, with the black thick line representing the retrace in the middle. That's where they must be aligned for a proper comparison.

Does the frame emulation in the fd0 case (the yellow square) fall *before* or *after* the vertical sync that you allow the fd 8 case to catch? It's either a before or after, no inbetween ;)

Quote
You are mistaking the start of emulation with the start of the emulator program.

What makes you think that I'm mistaking the two? How would that impact the analysis?

Quote
Quote
only then to come to the (obvious) conclusion that the fd0 case has one frame of lagging video (and audio)

This is not the conclusion, it's the premise!!  :D
It is a fact! The reason why we implemented frame delay in the first place. And you were there!  :D

Of course I was there, we were partying like it was 1999 :)

But... The fact that we came up with the whole framedelay concept was to get frame emulation as close as possible to the video display (vsync), to minimize input latency to almost the real hardware levels. This has little to do with case about audio latency I'm arguing here.

You may be mixing up / mingling two different cases:
- Input latency versus video display
- Audio latency versus video display.

They are two very different cases in emulator context. (Where you have to compensate for all kind of related buffer lags of the host system versus real hardware).

Of course I'd like someone else to prove me wrong, very much so, but unfortunately, I haven't seen any diagram or solid arguments that depicts that it's working differently than what I'm currently assuming and showing.


P.S. @ Intealls, sorry that we're highjacking your thread with this stuff! We'll get back to ASIO testing as soon as the next release is here, this is just inbetween chatter! :D
« Last Edit: June 30, 2015, 03:09:03 am by Dr.Venom »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #180 on: June 29, 2015, 02:13:01 pm »
If we only poll for input changes once per video frame, we have a problem, since the system we try to emulate instantaneously responds to input, regardless of when it happens.

We hold this debate long ago and concluded that this type of emulation ("frame-based" emulation) can only be "perfect" for games that poll input once per frame. If we could actually do scanline-based emulation (hsynced instead of vsynced) it should be possible to get closer to that. But that would probably mean rewriting all emulators, and serious implementation issues with video APIs that expect you to work with frames rather than scanlines.

Great, I *think* that was what Dr. Venom was reaching for?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #181 on: June 29, 2015, 02:32:25 pm »
The important conclusion I'm starting to draw is that with Framedelay at say 8 we are able to mimimize input latency versus real hardware, but it comes at a cost. The cost is that Audio latency is increasing by the amount that input latency is decreasing.

That's is utterly wrong, my friend.

Quote
Of course I'd like someone else to prove me wrong, very much so, but unfortunately, I haven't seen any diagram or solid arguments that depicts that it's working differently than what I'm currently assuming and showing.

With the material in this thread you should already accept my argument as proved. If you can't see it crystal clear, it's probably my fault and the limitations of my English. I think I give up now.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #182 on: June 29, 2015, 02:58:09 pm »
- Does the frame emulation in the fd0 case (the yellow square) fall before or after the vertical sync signal that you allow the fd 8 case to catch?
- What makes you think that I'm mistaking the start of emulation with the start of the emulator program?
« Last Edit: June 29, 2015, 03:23:25 pm by Calamity »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #183 on: June 29, 2015, 03:23:35 pm »
(Sorry I edited your post by accident when trying to answer, maybe you could restore it to its previous state  :( )

No worries Dr.

- Does the frame emulation in the fd0 case (the yellow square) fall before or after the vertical sync signal that you allow the fd 8 case to catch?

It falls after the vertical retrace, obviously. But that's let's say 1 ms after the fd 8 case, not the whole 16.7 ms as you're implying. The fact that in practice it makes the video start 16.7 ms later is exactly the problem we're trying to fight with frame delay, in other words, the misalignment of game logic and video output.

But what matters is that the game logic is aligned in both cases around t0 (well *nearly*). The game logic includes polling input and filling audio buffers.

Quote
- What makes you think that I'm mistaking the start of emulation with the start of the emulator program?

Because you're maintaing the fallacy (IMHO) that just because in the fd 0 case the first audio samples arrive to the speakers before they do in the fd 8 case, this means the audio latency is lower.

The reason why this is a fallacy is that latency only has a meaning when it is relative to the game logic (including input).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #184 on: June 29, 2015, 03:27:56 pm »
Regarding all this discussion about frame delay.

Currently, the flip queue is bypassed when using frame_delay with CRT Emudriver.

I was thinking, couldn't D3D9Ex (with the flip queue set to 1) be used, along with the frame_delay code, to provide next frame response with D3D to virtually any driver? This is all theoretical of course, I know nothing about the innards of a video driver. :)

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #185 on: June 29, 2015, 04:35:25 pm »
I was thinking, couldn't D3D9Ex (with the flip queue set to 1) be used, along with the frame_delay code, to provide next frame response with D3D to virtually any driver?

This should be currently possible with D3D9 too, although it's never been tested. The limitation is the time it takes the gpu to render the frame. While this is close to zero when using low resolutions (not necessarily CRT Emudriver), it becomes macroscopic when stretching over high resolutions is involved (typical case with nowadays monitors).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #186 on: June 29, 2015, 05:26:40 pm »
I was thinking, couldn't D3D9Ex (with the flip queue set to 1) be used, along with the frame_delay code, to provide next frame response with D3D to virtually any driver?

This should be currently possible with D3D9 too, although it's never been tested. The limitation is the time it takes the gpu to render the frame. While this is close to zero when using low resolutions (not necessarily CRT Emudriver), it becomes macroscopic when stretching over high resolutions is involved (typical case with nowadays monitors).

Thanks for the info!

Anyway, getting back to the topic at hand, here's 0.163 + ASIO, it contains a whole lot of changes and should work better in almost every regard.

0.163 r1.5

Edit: r1 fixes an issue with fastforwarding.

Edit: r1.5 contains a new batool version, with a drastically improved frequency calibration routine

IMPORTANT: -speed needs to bet set to 0.0, either start from a fresh ini or edit your existing one.

The pitch shifts (most of them) have been replaced with faint (most of the time) crackling, which is undoubtedly the lesser of two evils.

The sync disparity issue is gone.

Performance with frame_delay should be a lot better. Many thanks Calamity for helping me debug this!

I actually can't think of a single thing that ought to be worse compared to previous builds, aside from the fact that underruns might be more frequent, although they should be much harder to actually hear.

And also, a big thanks to everyone posting in this thread for their testing and feedback, and as always, please report any issues you might encounter.

0.163 is built with MinGW (without D3D9Ex patch), since changes done to this MAME version seem to break MSVC (2013) builds.

I've also decided to post an alternative 0.162 MSVC build with the D3D9Ex patch, since I've performed fairly extensive testing against this one.

http://www.mediafire.com/download/rl8hemtc4fwl2hr/gmame162-asio-msvc-d3d9ex.zip

Also, don't stare yourselves blind on the over-/underrun counter, I'll most likely change its behavior come next release.

Edit: Noticed minor error in patch, fixed in r1
« Last Edit: July 03, 2015, 04:54:50 am by intealls »

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #187 on: June 29, 2015, 06:14:48 pm »
(Sorry I edited your post by accident when trying to answer, maybe you could restore it to its previous state  :( )

No probs. It's shorter now, so I guess that's better :)

Because you're maintaing the fallacy (IMHO) that just because in the fd 0 case the first audio samples arrive to the speakers before they do in the fd 8 case, this means the audio latency is lower.

The reason why this is a fallacy is that latency only has a meaning when it is relative to the game logic (including input).

Thanks for all your answers in this discussion on framedelay and audio latency. I know I can be a little stubborn sometimes! I finally see your point of view and how perceived lower latency may fit the fd0 case (it's actually not really lower latency, as you said, that's why I put it in italics).

I made a new picture based on the one that you adjusted, with a few comments on the three approaches besides it. See the attachment. It was useful for me to reiterate and get my head around it!

Please let me know in case you have any suggestions for additional finetuning.

Anyway, getting back to the topic at hand, here's 0.163 + ASIO, it contains a whole lot of changes and should work better in almost every regard.

http://www.mediafire.com/download/wgoopf9d6ohka9e/gmame163-asio.zip

The pitch shifts have been replaced with faint (most of the time) crackling, which is undoubtedly the lesser of two evils.

The sync disparity issue is gone.

Performance with frame_delay should be a lot better. Many thanks Calamity for helping me debug this!

I actually can't think of a single thing that ought to be worse compared to previous builds, aside from the fact that underruns might be more frequent, although they should be much harder to actually hear.

And also, a big thanks to everyone posting in this thread for their testing and feedback, and as always, please report any issues you might encounter.

0.163 is built with MinGW (without D3D9Ex patch), since changes done to this MAME version seem to break MSVC (2013) builds.

I've also decided to post an alternative 0.162 MSVC build with the D3D9Ex patch, since I've performed fairly extensive testing against this one.

http://www.mediafire.com/download/rl8hemtc4fwl2hr/gmame162-asio-msvc-d3d9ex.zip

Many thanks intealls! Will be testing it soon and provide some feedback. Great stuff! :)

Also, don't stare yourselves blind on the over-/underrun counter, I'll most likely change its behavior come next release.

Could you possibly tell us a little bit more about that? May we still use it to benchmark with this release?

Edit: changed the picture slightly. fd 0 case is now called "least accurate", that's better than "inaccurate".
« Last Edit: June 29, 2015, 06:25:52 pm by Dr.Venom »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #188 on: June 29, 2015, 06:31:02 pm »
Many thanks intealls! Will be testing it soon and provide some feedback. Great stuff! :)

No problem. You should thank Calamity for helping out with the frame delay issue. That would have taken me a while to find. :)

Also, don't stare yourselves blind on the over-/underrun counter, I'll most likely change its behavior come next release.

Could you possibly tell us a little bit more about that? May we still use it to benchmark with this release?

Hmm, to change its behavior isn't really correct.

Currently, the strategy employed to handle overruns unfortunately tends to create a few underruns. I'm going to be quite busy the next few days, so rather than delaying the release and fixing this, I figured it's better to get it out, since it works so much better than the previous one.

However, it's much better if you guys would post the log created with -asio_log, since that makes it so much easier for me to understand what's going on, than simply the over-/underrun count, especially with this release.

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #189 on: June 30, 2015, 09:50:44 am »
Hi intealls,

Is it correct that the l.m script you posted earlier doesn't work with this release? I only get one garbled graph when running it in Octave.


intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #190 on: June 30, 2015, 11:24:22 am »
Hi intealls,

Is it correct that the l.m script you posted earlier doesn't work with this release? I only get one garbled graph when running it in Octave.

That's correct, here's an updated version!

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:September 25, 2020, 05:47:01 pm
Re: GM ASIO PRE-ALPHA
« Reply #191 on: June 30, 2015, 11:57:32 am »
Thanks a lot, Intealls.  I tested the .163 version briefly and agree that the crackling is much better than the pitch shifting.  I barely notice it.  Results with Frame_Delay also seem much better.  Tron was a game that required large buffers no matter what I tried before, but now it doesn't have obvious problems at the lowest settings and frame_delay 8.  Very nice.  Sorry I don't have any scientific results for now, I just wanted to voice my appreciation to you and Calamity for these improvements.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #192 on: June 30, 2015, 03:08:11 pm »
Thanks a lot, Intealls.  I tested the .163 version briefly and agree that the crackling is much better than the pitch shifting.  I barely notice it.  Results with Frame_Delay also seem much better.  Tron was a game that required large buffers no matter what I tried before, but now it doesn't have obvious problems at the lowest settings and frame_delay 8.  Very nice.  Sorry I don't have any scientific results for now, I just wanted to voice my appreciation to you and Calamity for these improvements.

No problem!

I'd say currently (given a correct calibration frequency), it's good enough to use as a 'daily driver', so to speak. Games with varying speeds like sfiii should also sound a lot better. They'll sound even better once I get around to properly fixing the over->underrun issue.

I've also done a lot of testing with the Xonar DGX, but I've noticed that the output sometimes crackle, it's especially noticeable in Deathsmiles. Aside from that, I'd say the driver appears tighter than kX.

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #193 on: July 02, 2015, 06:51:15 am »
That's correct, here's an updated version!

From preliminary (though extensive) testing I have some first findings. My testing has fully concentrated on the genesis driver using a superresolution (-resolution 1280x0) with the game Mega Turrican. This means that GM is actually scaling the internal genesis video by either a factor 4 (genesis 320 wide) or 5 (genesis 256 wide) during each "screenswitch".

The first finding was that the internal scaling on "screenswitches" in the game (as described in an earlier post) would negatively impact the audio stability. The testcase was to wait on the title screen for the demo mode to begin, then press fire (to go back to the title screen). Rinse and repeat. On most of the "screenswitches" an underrun would occur very shortly after the switch. After enough rinse and repeating I realized that I still had my HD 4830 in my machine from some testing a while ago. Thinking the internal video scaling could be involved, I changed the 4830 to my HD 4850. And indeed the previous underruns at the screenswitches were completely gone when using the same audio latency test settings. This implies that a fast(er) video card actually matters for sound/ASIO stability, when the driver switches screens and you're using a super resolution.

Next finding has more to do with the ASIO release itself. I found through using the Octave graphs that, on each time after starting the emulator, at the beginning there is some quite significant instability in the  number of samples in the audio buffers before stabilizing. This was repeatable over and over regardless of other settings. I finally gathered this had to do with the screenswitch that is done on emulator startup from the PC desktop resolution to the game resolution. I found a way of proving this, as you can enable "show game info" (skip_gameinfo 0) in the mame.ini, which together with "disable_nagscreen_patch  1" will physically switch the screen resolution from the desktop resolution to the groovymame resolution (1280x224) *before*  starting the game/driver,  to show some game information. This means that there's no screenswitching involved anymore at the moment the driver is started. And indeed, following this procedure the large instability in samples in the buffer at startup of the game / driver is gone. This can be repeated over and over.

I've attached two pictures, the one is of startup with screenswitching already done before driver start (skip_gameinfo 0) and the other with screenswitching at startup of the driver (skip_gameinfo 1).  You'll see that the first method has a much more stable profile at start (look at the Y scale values at start) than the second. This is the same for both using d3d and ddraw.

This seems to imply, that after a physical screen switch, the screen refresh rate may not be stable for a short time period. If that would be the case (maybe you can verify with your oscilloscope?), you could of course consider implementing a short delay after a physical  screenswitch before you enable the audio video synchronization algorithm. My hypothesis is that this would allow for the screen refresh to stabilize, and not actually perform "synchronization" on wrong values. But I may be wrong of course, possibly something completely different is causing this behaviour. Lastly, do note that I have attached both a CRT screen and an LCD to my PC, so maybe that impacts screen switching speed of the CRT.

A third finding was that using "multithreading 1" actually seems to generate less stable audio than having it off. It could especially be seen in the recorded speed against audio update. With multithreading off it would be a flat line, and with it on it would show minor variations in the line.

The fourth finding is that for the genesis driver at least, in combination with my system configuration, I need a marginally larger asio_holdoff (while using a calibrated callback frequency) than the default 864 to get really nice stable results at low driver latency. But once all this finetuning is done, the audio for this driver is running really stable!

P.S. I left testing of high framedelay values out of the equation for now (everything tested with fd 2), as I first want(ed) to get stable results before step by step increasing the fd value and see how that will impact the results.  Before testing this, I may wait for your next release first.
« Last Edit: July 02, 2015, 07:10:40 am by Dr.Venom »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #194 on: July 02, 2015, 03:41:55 pm »
That's correct, here's an updated version!

From preliminary (though extensive) testing I have some first findings. My testing has fully concentrated on the genesis driver using a superresolution (-resolution 1280x0) with the game Mega Turrican. This means that GM is actually scaling the internal genesis video by either a factor 4 (genesis 320 wide) or 5 (genesis 256 wide) during each "screenswitch".

The first finding was that the internal scaling on "screenswitches" in the game (as described in an earlier post) would negatively impact the audio stability. The testcase was to wait on the title screen for the demo mode to begin, then press fire (to go back to the title screen). Rinse and repeat. On most of the "screenswitches" an underrun would occur very shortly after the switch. After enough rinse and repeating I realized that I still had my HD 4830 in my machine from some testing a while ago. Thinking the internal video scaling could be involved, I changed the 4830 to my HD 4850. And indeed the previous underruns at the screenswitches were completely gone when using the same audio latency test settings. This implies that a fast(er) video card actually matters for sound/ASIO stability, when the driver switches screens and you're using a super resolution.

Nice find!

Next finding has more to do with the ASIO release itself. I found through using the Octave graphs that, on each time after starting the emulator, at the beginning there is some quite significant instability in the  number of samples in the audio buffers before stabilizing. This was repeatable over and over regardless of other settings. I finally gathered this had to do with the screenswitch that is done on emulator startup from the PC desktop resolution to the game resolution. I found a way of proving this, as you can enable "show game info" (skip_gameinfo 0) in the mame.ini, which together with "disable_nagscreen_patch  1" will physically switch the screen resolution from the desktop resolution to the groovymame resolution (1280x224) *before*  starting the game/driver,  to show some game information. This means that there's no screenswitching involved anymore at the moment the driver is started. And indeed, following this procedure the large instability in samples in the buffer at startup of the game / driver is gone. This can be repeated over and over.

I've attached two pictures, the one is of startup with screenswitching already done before driver start (skip_gameinfo 0) and the other with screenswitching at startup of the driver (skip_gameinfo 1).  You'll see that the first method has a much more stable profile at start (look at the Y scale values at start) than the second. This is the same for both using d3d and ddraw.

This seems to imply, that after a physical screen switch, the screen refresh rate may not be stable for a short time period. If that would be the case (maybe you can verify with your oscilloscope?), you could of course consider implementing a short delay after a physical  screenswitch before you enable the audio video synchronization algorithm. My hypothesis is that this would allow for the screen refresh to stabilize, and not actually perform "synchronization" on wrong values. But I may be wrong of course, possibly something completely different is causing this behaviour. Lastly, do note that I have attached both a CRT screen and an LCD to my PC, so maybe that impacts screen switching speed of the CRT.

The refresh rate is going to be stable, however, the game speed at start up is not. I think MAME needs some time to get in tune, this is kept 'in check' by setting -noskip_gameinfo and -disable_nagscreen_patch, since the emulator will pause at startup, letting everything initialize in the background. If aiming for as perfect emulation as possible, one should definitely consider setting these. Great observation!

A third finding was that using "multithreading 1" actually seems to generate less stable audio than having it off. It could especially be seen in the recorded speed against audio update. With multithreading off it would be a flat line, and with it on it would show minor variations in the line.

The fourth finding is that for the genesis driver at least, in combination with my system configuration, I need a marginally larger asio_holdoff (while using a calibrated callback frequency) than the default 864 to get really nice stable results at low driver latency. But once all this finetuning is done, the audio for this driver is running really stable!

Good to hear it. :) Many thanks for pointing this out. I think the holdoff should be changed so that it can be evenly divided with the ASIO latency. I see you're using a buffer size of 128 samples, with the default holdoff of 864, that gives 864/128 = 6,75, which is suboptimal, since BASSASIO will most likely (not guaranteed) be fetching latency-sized chunks. If increased to 896, BASSASIO could do about 7 fetches without getting new sample additions from GM.

I'm going to have to look into multithreading behavior.

P.S. I left testing of high framedelay values out of the equation for now (everything tested with fd 2), as I first want(ed) to get stable results before step by step increasing the fd value and see how that will impact the results.  Before testing this, I may wait for your next release first.

Great! Thanks a lot for these thorough tests. I'm currently trying to figure out a way to get the calibration time down, and when that's done, I'm going to try and sort out the buffer issues shown in the bottom graph of your post.

Edit: Also, as Calamity has pointed out, ddraw will not be available in future Windows versions, so all my current and future testing has been and will be performed against D3D.
« Last Edit: July 02, 2015, 04:16:07 pm by intealls »

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #195 on: July 03, 2015, 08:41:06 pm »
The refresh rate is going to be stable, however, the game speed at start up is not. I think MAME needs some time to get in tune, this is kept 'in check' by setting -noskip_gameinfo and -disable_nagscreen_patch, since the emulator will pause at startup, letting everything initialize in the background. If aiming for as perfect emulation as possible, one should definitely consider setting these. Great observation!

Thanks, good to know how this works.

A third finding was that using "multithreading 1" actually seems to generate less stable audio than having it off. It could especially be seen in the recorded speed against audio update. With multithreading off it would be a flat line, and with it on it would show minor variations in the line.

The fourth finding is that for the genesis driver at least, in combination with my system configuration, I need a marginally larger asio_holdoff (while using a calibrated callback frequency) than the default 864 to get really nice stable results at low driver latency. But once all this finetuning is done, the audio for this driver is running really stable!

Good to hear it. :) Many thanks for pointing this out. I think the holdoff should be changed so that it can be evenly divided with the ASIO latency. I see you're using a buffer size of 128 samples, with the default holdoff of 864, that gives 864/128 = 6,75, which is suboptimal, since BASSASIO will most likely (not guaranteed) be fetching latency-sized chunks. If increased to 896, BASSASIO could do about 7 fetches without getting new sample additions from GM.

Great, this does indeed make a noticable difference. It got me into further testing, and I was finally able to get to a fully stable (zero over-/underruns, and stable Octave graphical profile), at a whoppingly low latency of 48 with a holdoff of 576! We're talking 13ms of total audio latency here. That's really great!  See attached genesis-ddraw-bufsize48-holdoff576-fd2_showgameinfoscreen.png for the profile.

I've been testing both ddraw and d3d, but unfortunately d3d doesn't match the performance of ddraw. When running these low latency settings with d3d it will continuously underrun and/or crash the emulator. The lowest settings I got d3d to run without over- or underruns was with latency 48 and a holdoff of 864. But even then the profile doesn't look nowhere near as stable as the (lower latency) ddraw one. Just compare the previous one with genesis-d3d-bufsize48-holdoff864-fd2_showgameinfoscreen.png.

I also did some tests raising the framedelay value. After many tests, the conclusion is is that the higher the framedelay, the higher the audio latency needs to be to run the emulation without issues. In latency terms it's pretty much an inverse relationship, where unfortunately it seems that the audio latency needs to grow at a larger factor to accomodate for every additional unit (ms) in framedelay to keep the audio profile (perfectly) smooth.

At low latency (48/bufsize624) I can get to a framedelay of 4 while still keeping a very smooth profile, see genesis-ddraw-bufsize48-holdoff624-fd4_showgameinfoscreen.png. This again made me smile, I'm really happy with the result. Real hardware profile, here we come :)

After that I need to increase the audiobuffer by quite some margin to "fight" the spikes appearing in the audio profile.  For example at a framedelay of 5 I already need to raise the holdoff to 960 and then it still isn't as stable as fd4 at the lower audio latency setting (compare genesis-ddraw-bufsize48-holdoff960-fd5_showgameinfoscreen.png). At fd 6, the audiobuffer needs raising to 1280, but even then allowing for some spikes. This is both the case for d3d and ddraw, where d3d is again less stable, compare:

genesis-ddraw-bufsize128-holdoff1280-fd6_showgameinfoscreen.png
genesis-d3d-bufsize128-holdoff1280-fd6_showgameinfoscreen.png


Note that I performed all tests both for d3d and ddraw, but for every single of these tests d3d will perform worse (I've compared over 20 settings). Given your and vicosku's earlier results I expect the relative performance of d3d and ddraw to vary between drivers, but for the genesis driver it's pretty clear. 

Before I forget, what does the asio_playback_rate do in the settings? Could it somehow be used to further optimize settings?

Edit: Also, as Calamity has pointed out, ddraw will not be available in future Windows versions, so all my current and future testing has been and will be performed against D3D.

I understand the need to focus on d3d for a large part. The sad thing is that many of my tests show d3d to be inferior to ddraw.

As such I would like to raise a vote: Windows 7 is going to have extended support until 2020, so as long as ddraw is here (and as long as it's superior to d3d in certain aspects), please let us not forget about ddraw!

Apart from that, I'm -really- happy how the ASIO build is shaping up, great stuff, and great job from both you and Calamity! Thanks :)

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #196 on: July 04, 2015, 10:57:38 am »
Hi guys, sorry but I'm quite busy these days. Thanks a lot for the tests going on here. I'm happy to see a sort of agreement with Dr. Venom, finally.

Regarding the lower stability observed with -mt enabled, I think there's an explanation. In order to calculate current emulation speed, MAME measures the time elapsed once per frame. The exact point where this measurement is done is critical for the accuracy of the result. Usually, doing it right after we return from drawing is the best because the v-sync involved is more accurate than anything else. However, when running multithreaded, the draw operation is done in a separate blitting thread, while the main thread, where the speed measurement is to be performed, waits until it's signaled as ready by the blitting thread. This synchronization is done by means of an event object. The issue is, this mechanism requires the Windows scheduler to actually awake the main thread. This introduces an uncertainty relative to the time since we signal the event and the instant the thread is effectively awaken. This uncertainty doesn't happen when running single-threaded, as it will always take the same amount of cpu cycles to return from the drawing funtions back the main loop.

That said, the ultimate reason to use multithreading is to improve input response. So it should be determined if nowadays hardware still benefits from multithreading on this regard, as older hardware used to do. If this is still true, it might be possible to keep the multithreading just for input and force drawing and emulation in the same thread.

For the same reason, the advantage observed with ddraw seems to be directly related to the accuracy of the time it takes to ddraw to return. My understanding is this happens because ddraw involves no parallelization between cpu and gpu. That's what's behind the "superiority" of ddraw. If that is true, and we managed to completely break d3d parallelization, we'd achieve comparable results. The patch I posted some days ago had this purpuse, but it's poorly implemented. I'd like to do it *properly*. This means, it actually needs to grab data from the current modeline and make the timing dependent on absolute scanline numbers rather than uncertain "in-vblank" states. With that, it should really be very close to ddraw.

Although it's true W7 will be around for quite a long time, the fact is all the work I'm currently doing on the drivers is meant for relatively modern OS's and hardware (all my tests are for W8 now), and if it finally works some day, it'll be frustrating to have to stick to W7 just because of ddraw, so much work just to repeat the being-stuck-with-XP pattern, no please :)

It is also true that for the kind of synchronization we're seeking here, more powerful gpus might finally make some sense, as we'll need them to do all their scaling and stuff in the time of a few scanlines, in order to avoid static tearing.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:September 25, 2020, 05:47:01 pm
Re: GM ASIO PRE-ALPHA
« Reply #197 on: July 04, 2015, 02:51:01 pm »
That said, the ultimate reason to use multithreading is to improve input response. So it should be determined if nowadays hardware still benefits from multithreading on this regard, as older hardware used to do. If this is still true, it might be possible to keep the multithreading just for input and force drawing and emulation in the same thread.

Here's a video.  Looks like the input response is fairly on par with my multithreading videos.  Here is the line I used and my first 20 counts.  Intealls' recent .163 build was used.

mame64 sf2 -nomultithreading -frame_delay 8 -video d3d
Frame counts at 240FPS - 7,8,7,7,5,6,7,8,8,7,6,6,6,5,7,9,7,6,6,5

It is also true that for the kind of synchronization we're seeking here, more powerful gpus might finally make some sense, as we'll need them to do all their scaling and stuff in the time of a few scanlines, in order to avoid static tearing.

I'm using a 4550 on both of my machines right now.  After Dr. venom's post, I ordered a 4890.  I wanted it for some better performance in other games anyway, but it will be interesting to see if I experience any difference in GroovyMame.

Edit - I wanted to note that I am now using super resolutions, unlike in my previous tests.
« Last Edit: July 06, 2015, 03:15:31 pm by vicosku »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 311
  • Last login:October 11, 2020, 07:04:23 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #198 on: July 06, 2015, 01:32:36 am »
Great, this does indeed make a noticable difference. It got me into further testing, and I was finally able to get to a fully stable (zero over-/underruns, and stable Octave graphical profile), at a whoppingly low latency of 48 with a holdoff of 576! We're talking 13ms of total audio latency here. That's really great!  See attached genesis-ddraw-bufsize48-holdoff576-fd2_showgameinfoscreen.png for the profile.

That's quite amazing, with a latency that low, the Windows timer frequency starts to become a problem! Good to see the code holds up, at least in Genesis.

I've been testing both ddraw and d3d, but unfortunately d3d doesn't match the performance of ddraw. When running these low latency settings with d3d it will continuously underrun and/or crash the emulator. The lowest settings I got d3d to run without over- or underruns was with latency 48 and a holdoff of 864. But even then the profile doesn't look nowhere near as stable as the (lower latency) ddraw one. Just compare the previous one with genesis-d3d-bufsize48-holdoff864-fd2_showgameinfoscreen.png.

I also did some tests raising the framedelay value. After many tests, the conclusion is is that the higher the framedelay, the higher the audio latency needs to be to run the emulation without issues. In latency terms it's pretty much an inverse relationship, where unfortunately it seems that the audio latency needs to grow at a larger factor to accomodate for every additional unit (ms) in framedelay to keep the audio profile (perfectly) smooth.

At low latency (48/bufsize624) I can get to a framedelay of 4 while still keeping a very smooth profile, see genesis-ddraw-bufsize48-holdoff624-fd4_showgameinfoscreen.png. This again made me smile, I'm really happy with the result. Real hardware profile, here we come :)

Again, this is astonishing. What sound card/driver are you using? I don't think the cards I use with kX allow me to go to 48 without issues.

After that I need to increase the audiobuffer by quite some margin to "fight" the spikes appearing in the audio profile.  For example at a framedelay of 5 I already need to raise the holdoff to 960 and then it still isn't as stable as fd4 at the lower audio latency setting (compare genesis-ddraw-bufsize48-holdoff960-fd5_showgameinfoscreen.png). At fd 6, the audiobuffer needs raising to 1280, but even then allowing for some spikes. This is both the case for d3d and ddraw, where d3d is again less stable, compare:

genesis-ddraw-bufsize128-holdoff1280-fd6_showgameinfoscreen.png
genesis-d3d-bufsize128-holdoff1280-fd6_showgameinfoscreen.png


Note that I performed all tests both for d3d and ddraw, but for every single of these tests d3d will perform worse (I've compared over 20 settings). Given your and vicosku's earlier results I expect the relative performance of d3d and ddraw to vary between drivers, but for the genesis driver it's pretty clear.

Thanks alot for these tests! I currently don't have access to a proper testing rig, so I can't test the D3D patch Calamity posted a while back (more below).

Before I forget, what does the asio_playback_rate do in the settings? Could it somehow be used to further optimize settings?

-asio_playback_rate can be used to force a resampling rate, using it will ignore the game speed so it's mostly useful for debugging.

Edit: Also, as Calamity has pointed out, ddraw will not be available in future Windows versions, so all my current and future testing has been and will be performed against D3D.

I understand the need to focus on d3d for a large part. The sad thing is that many of my tests show d3d to be inferior to ddraw.

As such I would like to raise a vote: Windows 7 is going to have extended support until 2020, so as long as ddraw is here (and as long as it's superior to d3d in certain aspects), please let us not forget about ddraw!

Apart from that, I'm -really- happy how the ASIO build is shaping up, great stuff, and great job from both you and Calamity! Thanks :)

Thanks a lot for your for tests! I don't think I would have attempted testing buffer sizes/latencies this low, so it's decidedly great to see this sort of stuff :)

Hi guys, sorry but I'm quite busy these days. Thanks a lot for the tests going on here. I'm happy to see a sort of agreement with Dr. Venom, finally.

Regarding the lower stability observed with -mt enabled, I think there's an explanation. In order to calculate current emulation speed, MAME measures the time elapsed once per frame. The exact point where this measurement is done is critical for the accuracy of the result. Usually, doing it right after we return from drawing is the best because the v-sync involved is more accurate than anything else. However, when running multithreaded, the draw operation is done in a separate blitting thread, while the main thread, where the speed measurement is to be performed, waits until it's signaled as ready by the blitting thread. This synchronization is done by means of an event object. The issue is, this mechanism requires the Windows scheduler to actually awake the main thread. This introduces an uncertainty relative to the time since we signal the event and the instant the thread is effectively awaken. This uncertainty doesn't happen when running single-threaded, as it will always take the same amount of cpu cycles to return from the drawing funtions back the main loop.

That said, the ultimate reason to use multithreading is to improve input response. So it should be determined if nowadays hardware still benefits from multithreading on this regard, as older hardware used to do. If this is still true, it might be possible to keep the multithreading just for input and force drawing and emulation in the same thread.

For the same reason, the advantage observed with ddraw seems to be directly related to the accuracy of the time it takes to ddraw to return. My understanding is this happens because ddraw involves no parallelization between cpu and gpu. That's what's behind the "superiority" of ddraw. If that is true, and we managed to completely break d3d parallelization, we'd achieve comparable results. The patch I posted some days ago had this purpuse, but it's poorly implemented. I'd like to do it *properly*. This means, it actually needs to grab data from the current modeline and make the timing dependent on absolute scanline numbers rather than uncertain "in-vblank" states. With that, it should really be very close to ddraw.

Thank you for the detailed explanation! I tried the patch, but didn't do extensive testing. I was about to, but it seemed that many ASIO issues could righted with the existing frame_delay code by setting m_speed with a slight holdoff (consistent speed for 1 second). With that said, with the above rationale and the results Dr.Venom has posted, I can't wait to get to trying it out again (currently no access to a proper GM rig). Also, when I tried the patch, I noticed static tearing, perhaps due to CRT Emudriver using a different line count scheme than the driver used for development?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6956
  • Last login:Today at 06:42:49 am
  • Quote me with care
Re: GM ASIO PRE-ALPHA
« Reply #199 on: July 06, 2015, 04:25:39 am »
Thank you for the detailed explanation! I tried the patch, but didn't do extensive testing. I was about to, but it seemed that many ASIO issues could righted with the existing frame_delay code by setting m_speed with a slight holdoff (consistent speed for 1 second). With that said, with the above rationale and the results Dr.Venom has posted, I can't wait to get to trying it out again (currently no access to a proper GM rig). Also, when I tried the patch, I noticed static tearing, perhaps due to CRT Emudriver using a different line count scheme than the driver used for development?

Oh, ok that totally changes things. I was assuming all recent tests had been done with the new frame delay code. Tearing was expected by the way. I was surprised no one reported it, now I see why. That's what will be hopefully fixed with the proper implementation (modeline dependent). Now Dr.Venom's results with d3d make more sense to me. You can't expect speed stability comparable to ddraw with the existing fd patch and d3d. To summarize, the ultimate goal of the changes I've been suggesting is exactly that: to get ddraw-accurate speed through d3d with minimum latency, so we can eventually get rid of ddraw. First attempt, with d3d9ex, so the manual v-sync hack was unnecessary (fail). Second attempt, accept the fact that manual v-sync hack is going to be required but do an extra syncronization before returning to improve speed accuracy (approximate ddraw-accurate speed by breaking parallelization).

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi