VGM driver slow?

MrKsoft · Post by **MrKsoft** » Fri Feb 28, 2014 2:58 pm

Hi, I'm just getting into playing with SGDK. To practice, I've made a simple text based program that lets you choose between two VGMs to play.

Anyway, I noticed that as soon as more than a few channels start playing, the music doesn't run at full speed any more. I was just wondering if this is normal (since it's totally possible that processing VGMs is too much for the Genesis, or the driver isn't optimized yet), or if I'm doing something wrong. Would I be better off using an alternate driver?

Stef · Post by **Stef** » Fri Feb 28, 2014 3:18 pm

Unfortunately this is the only available VGM driver in SGDK.
You have to know the driver was wrote in C and work on the Z80 cpu so it is definitely not optimized and so you can experience slowdowns when playing heavy VGM file. Did you try to "optimize" your VGM file (thre are tools for that) ? sometime it can help

MrKsoft · Post by **MrKsoft** » Fri Feb 28, 2014 4:12 pm

I totally understand, and actually figured that was the case. They are optimized VGMs, so it looks like I won't get getting it any faster. No problem though, I can just use something other than VGM. It was just a test, anyway.

Stef · Post by **Stef** » Fri Feb 28, 2014 8:16 pm

VGM is a handy format for tons of reasons even if it is defenitely not the best one in term of size and processing. It would be nice to have a fast VGM Z80 driver in SGDK, that is definitely something i would like to try when i will have some time to spent on that

Chilly Willy · Post by **Chilly Willy** » Fri Feb 28, 2014 10:56 pm

I'll work on an assembly Z80 VGM driver this weekend.

Stef · Post by **Stef** » Fri Feb 28, 2014 11:14 pm

Oh really ? this is a good

do you eventually plan to sort of SFX support (PCM format) as the current C version ? it would be nice to have it as well =)

r57shell · Post by **r57shell** » Sat Mar 01, 2014 1:00 am

I think, one of main problem is sync.
Because, there is no good source for sync, to write registers at timing it's required. But it is just my theory

Second, as usually, PCM samples. Pain in ass :S

Chilly Willy · Post by **Chilly Willy** » Sat Mar 01, 2014 8:25 am

Stef wrote:Oh really ? this is a good do you eventually plan to sort of SFX support (PCM format) as the current C version ? it would be nice to have it as well =)

Yeah, I'll try to make it as compatible as possible... but better.

kubilus1 · Post by **kubilus1** » Sat Mar 01, 2014 9:19 pm

Yeah, I wrote most of the existing vgm driver. I've optimized swaths of it in asm, but there is definitely room for improvement.

You may want to check the frequency of the PCM samples you are using. The driver assumes 8khz, if they are longer then it could slow down the entire playback. Likely this is the case.

I've run some pretty heavy duty non PCM vgms through it without slowdown, by I suppose it would be possible to throw too much at it.

kubilus1 · Post by **kubilus1** » Sat Mar 01, 2014 9:24 pm

The real trick, as I've found, is dealing with the bank switching. Since the PCM files can play at any time from any ram location, it seems hard to avoid a lot of banking. I'm curious ChillyWilly if you have some more ideas around theses issues?

My goal with existing driver was to have convenience of use. Doesn't matter the starting ram location, type of PCM format (aside from hz), location of SFX in ram, etc. Perhaps trading off some of the conveniences for perf would be okay.

kubilus1 · Post by **kubilus1** » Sat Mar 01, 2014 9:28 pm

MrKsoft, if you would be so kind as to send me the links to those VGMs, I may be able to help determine why they are running slow.

kubilus1 · Post by **kubilus1** » Sat Mar 01, 2014 9:28 pm

Chilly Willy wrote:Yeah, I'll try to make it as compatible as possible... but better.

Awesome!

Stef · Post by **Stef** » Sun Mar 02, 2014 9:57 am

kubilus1 wrote:The real trick, as I've found, is dealing with the bank switching. Since the PCM files can play at any time from any ram location, it seems hard to avoid a lot of banking. I'm curious ChillyWilly if you have some more ideas around theses issues?

My goal with existing driver was to have convenience of use. Doesn't matter the starting ram location, type of PCM format (aside from hz), location of SFX in ram, etc. Perhaps trading off some of the conveniences for perf would be okay.

Maybe you are right and that the only problem was coming from the higher rate of the PCM. For bank switching the only thing you need is to use buffer:
You set bank switch and then read several PCM sample at once.
In my drivers i read 256 bytes at once for instance. Then you can set back to the VGM file bank to parse it. This way you can really improve the performance of your driver and you can even goes further: try to not use the 68k BUS during VBlank period to keep good PCM playback even during DMA =)

kubilus1 · Post by **kubilus1** » Sun Mar 02, 2014 4:30 pm

Stef wrote: For bank switching the only thing you need is to use buffer:
You set bank switch and then read several PCM sample at once.
In my drivers i read 256 bytes at once for instance. Then you can set back to the VGM file bank to parse it. This way you can really improve the performance of your driver and you can even goes further: try to not use the 68k BUS during VBlank period to keep good PCM playback even during DMA =)

So here are some of the challenges with getting good PCM with the VGM format specifically. These aren't necessarily insurmountable, but would need to be dealt with.

PCM samples in VGM files will be in one of two formats, separated out into individual PCM sections that define the sample, or one big PCM section that we index into (You actually can have the separate PCM sections and index into these as well, but I don't think I've seen this in the wild)

So for individual PCM sections it would be possible to load up the first 256 bytes into RAM. The trouble is, during playback these buffers can only be played out, or filled when the VGM song is not doing something else. We want to be sure we are playing other notes while PCM is going on, afterall. This buffer fill will be the time we potentially bank switch, so we could chew up a large chunk of time here.

During a busy VGM song we can't guarantee how much time we will have to perform these operations, unlike a situation where we are only playing PCM at a certain rate and know that we have X number of cycles to complete reading in the buffer.

Likely this may involve buffering as much as possible with the possibility of having to play buffers back before they are fully loaded and the tracking of half filled buffers. Not insurmountable, but tricky.

With the second format for PCMs, we will not know ahead of time where in the VGM file these samples will start from. The indexing could occur at any point during the playback of the PCM data. This really is the same situation as SFX playback.

This has all the same issues above (obviously,) but would also require processing the entire VGM file to locate the playback locations and build out the buffers. Some VGM files can be rather lengthy and this may require some loading time. Again, not impossible, but necessary.

Also you mention avoiding Vblank, the obvious solution is to have everything buffered up for that. I suppose this can reduce the time for buffering even more, but really is necessary since DMA is kind of a big deal.

I would love to get to all of this, since I've used this project as a means to learn z80 assembly, but my real job has gotten in the way lately

A more talented z80 assembly slinger than myself could probably knock this out without too much trouble.

Stef · Post by **Stef** » Sun Mar 02, 2014 5:25 pm

I have to admit i don't know much about the VGM format :-/ I know it support different PCM command but honestly i would support only the new one rather than old one which is really heavy both in term of CPU usage of ROM size. The problem is not only the Z80 assembly skill to deal with all that but also the way you design the driver itself. I believe it is a very difficult task to achieve a VGM driver capable of complete buffering (even the VGM data) and handle good PCM playback at same time ! What you did is already a nice achievement and i'm very happy to be able to distribute it in SGDK as this is the first Z80 driver capable of playing music and SFX as same time =) Actually there is Echo but Echo requires specific format and is definitely not as easy to play with.

My goal as you may know is to even get multi PCM playback (up to 4 channels) and for that you don't have choice, you have to count cycles so you cannot use anymore C. All Z80 cycles slots are pre-allocated and you should be able to cover the worst case (4 PCM + heavy VGM data). Of course you will have limits as you have limited cycles per frame... Something i plan to do eventually is to write the driver and then write a VGM converter to convert any VGM file to a VGM which fit the driver restrictions (as fixed PCM playback and limited number of VGM commands per frame..).