Previous Page

by Nisto at 5:30 PM EDT on August 9, 2018
Okay, so I almost, almost got it working properly in HE. I used events and root counter 2 set to a target value of 44100 in interrupt mode. This even plays in viopsf without problems. It's still ever so slightly too slow though; in the span of 1 minute, it has desynced about 1.5 seconds compared to the OST CD version and Mednafen's output (which match pretty closely).
by kode54 at 11:48 PM EDT on August 10, 2018
Maybe you should also be using counts of how many root counter events you miss? That high of a resolution sounds like something that could easily lead to missed interrupts.
by Nisto at 6:36 AM EDT on August 11, 2018
Hmm, are you saying that the counter might increment past the target value and never trigger an interrupt? Or are there cases where something causes the counter to reset or something? I did notice when polling (non-interrupt mode) that it incremented in units of 18 after each GetRCnt call in a loop that just polled until the target value (or greater) was reached.
by kode54 at 6:35 PM EDT on August 11, 2018
I'm saying there may be cases where it increments and the interrupt is masked because it happens while you're still in an interrupt handler.
by Nisto at 10:31 PM EDT on August 11, 2018
The event handler essentially just sets a flag that the "main loop" checks for, so I doubt there are any additional interrupts ever occurring during that time.
by kode54 at 11:30 PM EDT on August 11, 2018
Well, if it's only setting a flag and not actually incrementing an atomic counter, then you could be missing interrupt events anyway, if the main loop doesn't repeat frequently enough for 44100Hz interrupts. I'm not really sure on the timing of the root counters.
by Nisto at 6:01 PM EDT on August 12, 2018
Ahh. Not sure if maybe there's been a miscommunication here, but the target value for a root counter is not like in the playback rate of streamed music. Instead, the lower the target value, the more frequent the interrupts occur. My guess at this point is that the count actually exceeds the target value a little every time the interrupt occurs, since a tick of root counter 2 is an eighth of the system clock. Either that, or the pitch defined for the IRQ key is not exactly 44100 Hz after all??? I mean, I've tried so many things now but I keep seeing this one specific sample in "CAVERN" at 1:00.666 instead of at 0:59.158 (as with SPU IRQs).

I did the math in a comparison against the output of viopsf (SPU IRQ timing) vs foo_psf (root counter 2 timing) and got this:

viopsf_time = 2609423 (samples)
foo_psf_time = 2675464 (samples)
rcnt_target = 44100
(rcnt_target / foo_psf_time) * viopsf_time = 43011

The time measured here was from the start up to a distinct sample that's clearly visible in both of the transcodes about a minute in. Indeed, setting the target value to 43011 does result in pretty much the same playback rate, but the value feels kind of arbitrary and there's not anything logic to prove its correctness I feel.

edited 6:03 PM EDT August 12, 2018
by kode54 at 5:32 PM EDT on August 13, 2018
Maybe it's because Highly Experimental's R3000 only syncs the timer cycle counts on register accesses or at the end of a batch of execution, not on every branch like some emulators do? (for instance, the N64 emulator mupen64plus)
by Nisto at 3:34 PM EDT on August 14, 2018
That does sound possible.

Question, is there any I/O register I can use to check the current address for a voice? Or anything at all that could indicate the playing progress of a sample?

According to the no$psx docs, there is a register that's supposed to be updated when the "loop end" flag is read, but at least in PSFLab and Mednafen, it doesn't seem like it ever is. Unfortunately so, because I had this idea:

1. Call SpuSetKey to trigger playback of a silent, looping sample at 44100 Hz
2. Call the MDX tick handler
3. Poll 0x1f801d7e ("loop end" register) until it's been updated to the address containing the flag
4. Reset 0x1f801d7e to 0 so we can use it again to determine if the "loop end" flag (last block) has been read
5. Keep looping over to step 2
by kode54 at 7:52 PM EDT on August 15, 2018
Oh, another thing. The emulator will also exit from execution early if it detects that the CPU is looping in an idle loop.

Previous Page
Go to Page 0 1

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source
Generated in 0.0029s;