PCM player using SCC

페이지 23/33
16 | 17 | 18 | 19 | 20 | 21 | 22 | | 24 | 25 | 26 | 27 | 28

By ARTRAG

Enlighted (6923)

ARTRAG의 아바타

25-10-2007, 13:44

My proposal bout interleave is, (keep the #of I/O you have now but that must for sure be changed):
18 bytes ch1
18 bytes ch2
18 bytes ch3
18 bytes ch4
12 bytes ch1
12 bytes ch2
12 bytes ch3
12 bytes ch4
18 bytes ch1
18 bytes ch2
18 bytes ch3
18 bytes ch4
12 bytes ch1
12 bytes ch2
12 bytes ch3
12 bytes ch4
...

By Manuel

Ascended (19273)

Manuel의 아바타

25-10-2007, 13:54

Hmm, I just tried to use the channel recorder with fifth.rom and when I do that, it sounds perfect. So, the emulation is OK, but there's something with the mixer or the resampler.

By dvik

Prophet (2200)

dvik의 아바타

25-10-2007, 17:40

In your code you update 32+2 samples per channel per frame
I know, it doesn't matter because sample 16 and 17 are copied twice. I just wanted to have some flexibility to change the first part of the copy. Its wasting a little bit of CPU but doesn't impact the playback.


why not updating one byte only, reset the scc, continue updating fot the last of one sample, and than move to the rest ?

Its better to copy as much as possible. The player is at sample 31 so copying 1 byte to sample 0 or the 18 first samples doesn't matter. The important thing is that the resets of the channels are spaced apart by one 7.6kHz sample.

moreover, just and idea, you can interleave the channel data in rom in order to avoid
all the adjustments

Yes, I just didn't know how much its copying in each copy. Storing 32 byte for each channel gives more flexibility though and doesn't tie the data to a particular implementation. These extra offset calculations doesn't take much cpu at all (only eight per frame).

By ARTRAG

Enlighted (6923)

ARTRAG의 아바타

25-10-2007, 17:51

In your code you update 32+2 samples per channel per frame
I know, it doesn't matter because sample 16 and 17 are copied twice. I just wanted to have some flexibility to change the first part of the copy. Its wasting a little bit of CPU but doesn't impact the playback.


why not updating one byte only, reset the scc, continue updating fot the last of one sample, and than move to the rest ?

Its better to copy as much as possible. The player is at sample 31 so copying 1 byte to sample 0 or the 18 first samples doesn't matter. The important thing is that the resets of the channels are spaced apart by one 7.6kHz sample.

Well, but why coping 2 old samples when you could copy NEW one :-)?
Is it doable ? I think yes, this would rise the Fs of some % (passing the 8KHz in any case)
and not waste any extra CPU than now.
(this because while you was updating the channels the SCC went on in using them,
so when you finished the copy of your 32 samples, you can update some of them
already used, rising the total number of sample played per frame, and thus
the FS. Am I mad ? It's trick but why not? :-)

BTW in order to explore this option some preliminary questions:

How do you know that the player is at sample 31 and not starting right now sample 0 ?

How does the real thing behaves when you change the value of the sample CURRENTLY being played ?
does it affect the output, and more important does it reset the TIMING OF THE PERIOD ?

I think that the timing of the period is reset when you change the byte being played and this
was a trick for playing PCM somewhere : put Fs very low and send wagons of data from the z80

By dvik

Prophet (2200)

dvik의 아바타

25-10-2007, 18:08


Well, but why coping 2 old samples when you could copy NEW one :-)?
Is it doable ? I think yes, this would rise the Fs of some % (passing the 8KHz in any case)
and not waste any extra CPU than now.
(this because while updating the channels the SCC went on in using them,
so when you finished the copy you can update some already used
rising the total number of sample played per frame :-)

Ah ok, yes thats doable and should indeed be done.

EDIT: This is somewhat tricky so I'll wait with this.


How does the real thing behaves when you change the value of the sample CURRENTLY being played ?

Not sure. The idea with this replayer is to avoid that. But I think something is wrong somewhere with the timing somehow. I need to do some more debugging to figure out. The real MSX doesn't sound good and the emulator sounds good with a period that doesn't seem to be correct (as you said earlier).


does it affect the output, and more important does it reset the TIMING OF THE PERIOD ?

If it did it could explain the phase problems I have on the real SCC.

If thats the case I only need to update the adaptive frequency finder (that syncs the SCC and VDP) so it works correct Smile

The idea is to reset a channel when it has been playing just a bit less than 32 samples (31.9 or so, the closer the better).

By ARTRAG

Enlighted (6923)

ARTRAG의 아바타

25-10-2007, 18:46


The idea is to reset a channel when it has been playing just a bit less than 32 samples (31.9 or so, the closer the better).

But if this is your idea, you have to adopt the strategy I said
updating with LDI the first sample (16cyles) resetting ASAP the
channel and than continue your update

In this way you can increase the freq and go very very close
to the end of the 32nd sample

By dvik

Prophet (2200)

dvik의 아바타

25-10-2007, 19:01

But if this is your idea, you have to adopt the strategy I said
updating with LDI the first sample (16cyles) resetting ASAP the
channel and than continue your update

Thats what the code is doing, except that its copying 16 bytes instead of one. but the reset happens at sample 31.9 and then the channel is reset and the new sample in position 0 will be played.


In this way you can increase the freq and go very very close
to the end of the 32nd sample

Thats indeed the idea.

By ARTRAG

Enlighted (6923)

ARTRAG의 아바타

25-10-2007, 19:03

But if you advance the reset (e.g. using my solution) you could increase the Fs
or not ?

By dvik

Prophet (2200)

dvik의 아바타

25-10-2007, 19:19

Not sure. If you do you need to reset the phase twice every frame. Otherwise you'll get a drift which will cause problems with those samples 15 and 16. Perhaps you can fill sample 0, let the scc wrap around and reset at sample 0.9 instead of 31.9. But the first goal is to get the player working at all so I'd wait with these improvements.

By ARTRAG

Enlighted (6923)

ARTRAG의 아바타

25-10-2007, 19:39

In order to do testing, I've found that even my processing does not avoid some rounding errors
those errors could mask other problems.

Can I suggest you to generate a simple waveform or to choose a signal for which there is no rounding
error before starting your tests?

You should test, while producing channel data, if the "reconstructed" result differ from the original
in order to select a sequence of input that does not suffer of this problem.

just evaluate the difference between z and Y in my matlab code to see where my formulas fail

(IMHO after solved all the other issues, this "rounding" problem will stay in any case)

페이지 23/33
16 | 17 | 18 | 19 | 20 | 21 | 22 | | 24 | 25 | 26 | 27 | 28