Been working on this for a few days. It’s pretty decent IMO. The song is Siren. I need to finish polishing it up, but I’m gonna use this for the next version testing of the XM converter and player.
Archive for June, 2010
Recorded from the real system this time. Since doing my last batch of audio tests, I fixed some popping issues on version 1.0.10 on the real system (also fixed a bug where some samples weren’t playing). Video record is poor, but sound is clear and great (original white PC Engine). Man, I really need to fix that high-pass noise on this little system. My TG16’s never had this. Need to figure out a low-pass setup for it.
Had some stuff to do the past couple of days. But now I’m free for a while. Gonna resume more tests tomorrow 🙂
Been doing a lot of audio tests. Found some interesting things, some fairly important for audio/music engines. Still have a lot more tests to do, but I’m taking a breather and posting this:
(click to see full size)
Just some DAC characteristics that I didn’t think about. Normally, you see a lot of “return of zero/centerline” with PCE audio and tests. As in, the leaning of the samples (relative to the audio line) would point towards center line, relative to which polarity the sample it current residing. Especially for sample stuff, because of the low frequency of sample updates (and strings of duplicate samples in a row).
This pic is of a snare sample. It has a lot of sample updates (non redundant runs of samples). If you look at the red lines on the top channel, you can see the slant is towards the next sample, not centerline (green). It’s the channel’s DAC ramping up (and down) voltage to the next sample. Pretty much just like oversampling (or linear point filtering), except this doesn’t happen on the PCE if the sample update is too low. Lower than 7khz. It makes certain samples on DDA a tiny bit softer on the real system too. Just something to think about.
From a few audio captures I did yesterday, I found something peculiar. If you string a bunch of sample data to the DDA port (in DDA mode), with the volume something relatively loud and you wait for the DAC to ‘return to zero (centerline), and then you set the volume to silence ($c0) – you’ll get an interesting pop on the DAC line (assuming the last sample was far enough away from center line to give that effect).
This ‘pop’ has a return to zero phase like that if you write a sample and let it drift. And yet, no sample was written. And it’s not an audio spike and then quickly back to centerline. This pop seems to be only relative to a pan left/right that’s active (not silenced).
Now, $c0 is supposed to be the lowest volume – silence. But I don’t think it silences the DAC so much as it just prevents any sample output (be it DDA or normal channel mode). That’s a big difference. The weird thing is, is that the last sample written to DDA seems to get re-output on the DAC before is ‘off’. I’d go a step further and say that not only is the being silenced with the lowest volume setting, it’s probably just turning the DAC off all together. The equivalent to writing $00 to $804. IIRC, Air Zonk curiously puts a channel normal into DDA mode and writes $0f before shutting it off to update the channel buffer.
So with that, I have more tests to do today 😀
I have no idea why, but yeah. I found a bug in the XM to PCE converter. Any instrument manually set to full volume was being silenced. Mostly snare samples, I believe. Louis’ XM sound damn awesome on the real system with the current test rom.
But, I noticed something. I’d get these slight ticks here and there. Did a lot of testing and special case code for buffer updates and what not. Seems there are some issues when dealing with DDA mode and trying to use the volume reg at the same time. Hopefully not to big of a deal (I just need to write special case code for it). The surprising thing is, I didn’t see any small pops for doing close instrument changes – like I expected to see.
This of course makes me happy, cause I tried many hours/days last year trying to get a buffer mode PCM playback routine. While it worked on the SGX, it didn’t on the other systems. So, gonna do some more tests tomorrow (did a bunch of tests today with video, but nothing new was found).