Rate of streaming data to the SPC700?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Rate of streaming data to the SPC700?

Post by Drew Sebastino »

This has been beaten to death, but I've never actually understood how it worked. I gather that the CPU has to write to audio ram through the SPC700 and they have to be "synched up", but what does this really mean? I guess it's that because the SPC700 operates at a lower frequency, you need to make sure you're writing to it when a cycle is happening on both, but the frequency of the main cpu and the SPC700 isn't even related at all, as 2.68/1= about 0.373, so I have no clue how this works. I guess it's never perfect, but I imagine there's a period of time a cycle takes up, so the SPC700 could get the data toward the end of a cycle and it wouldn't make a difference or something like that. Yeah, a cycle doesn't last until the next one, does it?

I was really wondering though is, in the 32KHz, 16 bit sound demo that apparently takes up all CPU time, is this because of decompression, or is it because of waiting for the right time to write to the SPC700? I don't even know what bit depth in sound is, but I guess it's just the range the sound wave can be at, so if I were to draw a line graph that represented sound waves, each axis would only have whole numbers and the y axis would be bit depth, and the x axis would be the "KHz" frequency. The thing is though, would you ever even really need to jump from 0 to 65536 in one Hz? Could you do a sort of lossy compression where instead of 16 bit audio, you have 8 bit audio where you can either go up 128 or down 128, or would this sound like crap even at 32KHz (or really, would this sound better than 16 bit 16KHz)? You'd also have to have the SPC 700 decompress it, which I'm not too sure how possible that is. I think I heard that the DSP (for the most part, but there's a way to get around it) actually uses lossless "BBR" compression (which I don't know how it's formatted, but I can look into it) but if it is lossless, than that means the rate of streaming could be inconsistent, unless you doctored all your samples to work around it and made them kind of lossy, but whatever. Ofcourse, constant streaming rate really only matters if you're streaming the data to the SPC700 and then streaming that data through the DSP right away in that you're not creating a buffer in audio ram.

I actually thought of something again... If the SPC700 were completely busy streaming data, couldn't it not even decompress any lossy audio samples? Grr...
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Rate of streaming data to the SPC700?

Post by lidnariq »

Normally, when you're talking to a friend, you know when to listen and when to talk by gestures and gaps in the conversation.

With the SNES, the S-CPU and the S-SMP have a much more restricted means of communication: there are exactly four boxes, each of which can hold a single number between 0 and 255. They can't know when the other side put a new number in: they can only see that the number has changed since the last time they checked.

Streaming uncompressed 32kHz stereo 16-bit audio requires transmitting approximately 128000 bytes per second. But the exact rate is determined by the S-SMP's clock, which isn't a constant speed relative to the S-CPU. (Because the S-SMP originally used a lower-precision "ceramic resonator", it can drift by up to 0.1% from what's intended, while the S-CPU uses a calibrated quartz crystal)

So the S-CPU not only has to push 128000 bytes per second through this cramped communication path, but it has to ask the S-SMP whether it needs more data yet. And the S-SMP has other things it has to do, too, namely copy the data from the S-CPU to the DAC (which is complicated, but we'll ignore that for now)


As far the other questions, I'd strongly recommend xiphmont's tutorials.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Rate of streaming data to the SPC700?

Post by Bregalad »

If the SPC700 were completely busy streaming data, couldn't it not even decompress any lossy audio samples? Grr...
The audio is always lossy compressed in the SPC700. The hardware decompress it just in time when it extract samples from BRR encoded data. There is not much point in compressing it further with another algorithm, because the data is already close to full randomness, which makes it extremely difficult to compress.

The only way this could be done is separateing BRR sample data itelf (last 8 bytes of each 9 byte BRR packet) and BRR data hearders (first byte of BRR packet), and while the audio data is incompressible the headers are, with RLE or huffman. The problem is that in the absolute best case you reduce data to 8/9 of it's original size, which is not very interesting.

Also, please do not use "grr" or anything like that in your post, this is not appropriate. It might not be the intent, but it makes you sound like an aggressive dog threatening us, even though we're not responsible of the issue (in this case SNES hardware development).

One major problem for SPU/CPU sync is that both runs on completely separate crystals, unlike, say, the CPU and PPU in the NES, where they run at different rates, but based on different divisors of the same crystal.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Rate of streaming data to the SPC700?

Post by tepples »

There are different degrees of lossy. At times I've thought of how to compress mostly periodic samples, such as speech, by repeating smaller portions. And at times I've thought of how to compress audio at 2 bits per sample instead of 4, unpacking it to proper BRR at runtime. (I can't do any experiments at the moment because of The Curse of Possum Hollow.)


EDIT (2016-11-12): 2-bit BRR is on
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Rate of streaming data to the SPC700?

Post by 93143 »

Espozo wrote:you need to make sure you're writing to it when a cycle is happening on both
It looks like you have a fundamental misconception happening here.

Communication between the two processors (the main CPU and the audio CPU) is accomplished by means of I/O ports that hold persistent values. You write to a port, with either processor, and the value you wrote shows up on the other side for all time, or until the system is turned off, or until the port is written again from the same side (values read from these ports are always the values that were written from the other side).

http://wiki.superfamicom.org/snes/show/SPC700+Reference

"Sync" in this case doesn't mean cycle-alignment. It means making sure that (a) the S-CPU doesn't write a new value before the S-SMP has read the previous one, and (b) the S-SMP doesn't read an old value again and mistake it for new data. (Also (c) the S-SMP doesn't end up with corrupted data due to reading during an S-CPU write, or reading the top port after the bottom two ports were written in rapid succession. See the link above for descriptions of these two hardware bugs.) There are lots of ways to accomplish this, from two-way handshake protocols for each byte (slow but reliable in a variety of situations; the SPC700's boot ROM does this) to semi-free-running timed code loops (fast but require intermittent sync protocol to account for the fact that the clock ratio is not reliable). N-Warp Daisakusen's audio streaming uses multi-line HDMA bursts on the S-CPU side and a cycle-counted read loop on the S-SMP side, but its peak bandwidth is limited by the fact that it dumps the data on the stack and copies it to the desired location after the burst. My own (untested) attempt at HDMA streaming uses self-modifying code to pass the data straight to the desired location during the read loop, which should in principle allow much higher bandwidth. (Again, my code is totally untested; for all I know, d4s' method could be the best you can do with HDMA...)

blargg's uncompressed 32 kHz 16-bit stereo streaming technique uses single-sided sync from the S-SMP (since that's the side that knows exactly how fast the audio is playing) and writes the data to a fixed location in audio RAM to avoid the overhead of indexing and page handling. Playback is via an echo buffer exploit: If you set the echo buffer size to zero, it will continually pick up the echo sample from the same four bytes (16-bit stereo = 4 bytes per sample), so if you can write to that location at an absolutely consistent rate of four bytes per 32 S-SMP cycles, you can play arbitrary 32 kHz stereo sound. Unfortunately the S-CPU has to pay very close attention to the I/O ports to pull this off; there's room for extra processing since it's so much faster than its counterpart (blargg used a lossless compression algorithm to jam more audio into the ROM) but the whole thing has to be designed around the audio streaming loop because the S-CPU has to reliably be there for the S-SMP approximately twice per scanline.

Basically, lidnariq describes the situation pretty well. You have four I/O ports as described, and whatever you do has to work reliably given that constraint.
Espozo wrote:The thing is though, would you ever even really need to jump from 0 to 65536 in one Hz? Could you do a sort of lossy compression where instead of 16 bit audio, you have 8 bit audio where you can either go up 128 or down 128
That sounds like DPCM. The NES uses 1-bit DPCM for its sample channel, which is why it sounds so awful.

BRR is a type of ADPCM.
If the SPC700 were completely busy streaming data, couldn't it not even decompress any lossy audio samples?
The nice part about BRR is that it's used natively by the S-DSP. The S-SMP doesn't need to worry about it. (Unfortunately, since the S-DSP can't use uncompressed audio, it's hard to do software synthesis; to avoid having to do BRR compression you'd have to use the echo buffer, and the echo buffer is unavoidably 32 kHz stereo, which is really hard work for these primitive chips...)

...

The nice part about the MSU1's streaming functionality is that it bypasses essentially the entire SNES, passing analog audio directly to the output stage of the APU via a pair of cartridge slot pins designed for exactly this. Eight channels of sound effects, anyone?
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Rate of streaming data to the SPC700?

Post by Near »

Bregalad wrote:Also, please do not use "grr" or anything like that in your post, this is not appropriate. It might not be the intent, but it makes you sound like an aggressive dog threatening us, even though we're not responsible of the issue (in this case SNES hardware development).
Are ... are you joking? Because you can't possibly be serious. But if you are ... you got it.
93143 wrote:Communication between the two processors (the main CPU and the audio CPU) is accomplished by means of I/O ports that hold persistent values.
I still need to revise that. My understanding is that there are eight actual byte values, and all of them reside inside the SMP. Not that it makes a difference from a user programming perspective, of course. But for documentation purposes, it'd be good to know for sure and get it right.

Right now I have it that CPU $2140-2143 (mirrored through 217f) hold four bytes; and SMP $f4-f7 hold four bytes as well.
* CPU read => return SMP bytes
* CPU write => assign CPU bytes
* SMP read => return CPU bytes
* SMP write => assign SMP bytes
If they are really all inside the SMP, then four of the bytes don't actually exist in RAM anywhere (the SMP ones actually are stored in the APURAM itself.)
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: Rate of streaming data to the SPC700?

Post by AWJ »

byuu wrote:If they are really all inside the SMP, then four of the bytes don't actually exist in RAM anywhere (the SMP ones actually are stored in the APURAM itself.)
That's something I really think you need to check against hardware again, because it doesn't seem physically possible to me. The way higan implements the I/O ports, you can put the DSP echo buffer in APURAM page $00 and then the S-CPU can directly read four bytes of the echo buffer via $2140-2143. I don't see how that's possible memory-access-timing-wise. I think it's much more likely that SMP writes to $F4-$F7 also fall through to APURAM (just like writes to $FFC0-$FFFF fall through even when the IPLROM is mapped in), but the ports themselves are internal to the chip so they can be read asynchronously by the S-CPU.

In any case, there are definitely eight 8-bit ports, four which are read-only on the CPU side and write-only on the SMP side and the other four which are write-only on the CPU side and read- or erase-only on the SMP side.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Rate of streaming data to the SPC700?

Post by Drew Sebastino »

Thanks everyone for commenting. I think I get why it's so difficult, because I was thinking you could set aside a fixed amount of time for the 5A22 to do nothing but send data and the SPC700 to do nothing but receive data, but where the 5A22 would only use about 16 cycles to write 4 bytes (16 bit accumulator, 2 4 cycle lda's, 2 4 cycle sta's) the SPC700, assuming it's like the 6502, would take I think 24 cycles to write 4 bytes (only 8 bit accumulator, 4 3 cycle lda's, 4 3 cycle sta's). Not only that, but the SPC700 is only like 2/5's as fast as the main cpu, so get 6 cycles (24/4) times 2.68 = 16.08, times 128,000 = 2,058,240. :(

I don't quite get the whole feedback thing though, if you're only sending data to the SPC700, why would you need this whole "handshake" thing? It seems you'd just need to have your audio ram filling code calibrated with the SPC700's speed, and you would be fine, unless that speed fluctuation is that bad, but you could still calibrate the code around it because I'd imagine it's fairly predictable?

Just thinking some more, I imagine HDMA would send something like 1024 bytes over in one frame (it works during vblank, doesn't it? how long is the "screen" on the SNES, including "off the screen"?), and 128,000/60 = 2,133, and 1024 just about knocks half of that out. Use BRR compression instead of the echo buffer thing, and you don't even have to worry. Could you actually fire an interrupt (that would work for the 5A22, and hopefully the SPC700) every line instead of HDMA, so you could still use all 8 HDMA channels for the video hardware that requires you to send it then? I mean, when HDMA is done, fill out the 4 IO ports then. You could even do it to where the CPU fills out them in 16 cycles like I was talking about earlier, wait about 60 (doing hopefully something, in worst case nop's) and then use another 16 cycles and be done? That would knock out about the rest of the 2,133 bytes, Actually, I just found out, this is now still about half of the CPU time... :lol:

Is there a program out there that will turn a music sample into BRR format, and either back or let you play it, because I'm interested in seeing how lossy it is. It can't be that bad, considering how clear a lot of the Donkey Kong Country music is and I doubt it's at 32KHz either.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Rate of streaming data to the SPC700?

Post by lidnariq »

Espozo wrote:alibrated with the SPC700's speed, and you would be fine, unless that speed fluctuation is that bad, but you could still calibrate the code around it because I'd imagine it's fairly predictable?
You can't calibrate just once against something that drifts.

You can probably save a little time by resynchronizing less often, but even so.
[HDMA] works during vblank, doesn't it?
No.
hopefully the SPC700
The S-SMP has no interrupt sources.
Is there a program out there that will turn a music sample into BRR format, and either back or let you play it, because I'm interested in seeing how lossy it is. It can't be that bad, considering how clear a lot of the Donkey Kong Country music is and I doubt it's at 32KHz either.
The SNES APU is a wavetable synthesizer. Individual samples tolerate lossy compression noise a lot better than whole audio streams.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Rate of streaming data to the SPC700?

Post by tepples »

My Super NES project template includes a BRR encoder written in Python. I think it can also decode.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Rate of streaming data to the SPC700?

Post by Drew Sebastino »

lidnariq wrote:You can probably save a little time by resynchronizing less often, but even so.
That's what I was thinking. The real problem seems to be the fact that the speed varies randomly, not the fact that the speed is different.
lidnariq wrote:No.
:(
lidnariq wrote:The S-SMP has no interrupt sources.
Oh... So it constantly has to be doing nothing other than looking at the IO ports? I'm not sure how that's going to work. How does HDMA work for this then? Can the S-SMP generate interrupts for the S-CPU? That would be a miracle, but I bet it's too good to be true.
lidnariq wrote:Individual samples tolerate lossy compression noise a lot better than whole audio streams.
That's what I would have figured do to the fact the sound wave is much less complicated. I guess one thing you could do is only have the audio be mono, and reduce the 128,000 bytes per second to 64,000 bytes per second. Non mono music really doesn't make sense anyway, considering the music isn't actually coming from the game onscreen anywhere. Sound effects being stereo is important to me though, and that's not hard to do. Yeah, mono sounds fine, just 64,000 divided by 60 for 1,067 bytes, and 224 times 4 is 896. It can't be that hard to send 171 bytes (hopefully) and if it is, I doubt anyone would notice if the sampling rate was brought down to 26KHz, which is about 867 bytes, and HDMA could get rid of that by itself. (I imagine you could play it at a random sample rate like that?) I do really wonder if this sounds better than 32KHz BRR though, and this could be stereo. I'd have to test it on some tracks and see what I think sounds better, although I don't have any kind of tool that will turn a generic music file into a BRR and back.

A new post just came in...
tepples wrote:My Super NES project template includes a BRR encoder written in Python. I think it can also decode.
Sweet! :) I'll be sure to try it out (and probably even post the results here).

Edit: Unfortunately, it doesn't seem able to decode.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Rate of streaming data to the SPC700?

Post by psycopathicteen »

You know, now that you mentioned it, I wonder if the drifting SPC700 speed is why some of the music sounds different from how I remember it.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Rate of streaming data to the SPC700?

Post by 93143 »

Espozo wrote:I was thinking you could set aside a fixed amount of time for the 5A22 to do nothing but send data and the SPC700 to do nothing but receive data
You can. It's just a substantial hit to S-CPU power if you want high bandwidth. I think the Bad Apple demo does this, but with a low-rate mono stream.

The advantage of HDMA is that the S-CPU can go do something else. It's actually slower than a tight handshake loop, but it's automatic on the S-CPU side.
128,000
That's well past the theoretical maximum data rate on the S-SMP side. The only reason it works is the fixed destination address in zero page, so it can be written with non-indexed direct-page word writes. You can't fill arbitrary areas of ARAM that way.
I imagine HDMA would send something like 1024 bytes over in one frame
It only works in active display. You get 225 lines in normal mode, or 240 in overscan mode (it will fire at the end of line 0, which is blank because sprites, but apparently it will also fire at the end of the last active line when it shouldn't matter any more).

So an HDMA channel can transfer at most 900 bytes, or 960 bytes in overscan mode. But IIRC the observed variance in APU clock speed is such that a cycle-counted read loop could desync over that much time, and the loop is so tight that I doubt it's possible to resync without stopping the data flow temporarily. Besides, d4s is using the stack, and I'm relying on an 8-bit index register, so neither of our methods can handle more than 256 bytes in one chunk no matter what.

My method is designed to use bursts of up to 32 lines separated by resync (and, optionally, unrelated audio engine processing). If it works, it would peak around 750-800 bytes per frame, or less if you wanted to do other audio processing in between chunks so as to allow sub-frame audio timing. I'm hoping for 640 bytes (five chunks), which is enough for 32 kHz stereo BRR, or three 22 kHz streams (enough for Ryu, Ken, and the announcer), with enough wiggle room (hopefully) to allow adaptive chunk sizing and/or scheduling based on live timing checks.
how long is the "screen" on the SNES, including "off the screen"?
262 lines for NTSC, 312 for PAL. In interlace mode, every other frame has an extra line.
128,000/60 = 2,133, and 1024 just about knocks half of that out
That would knock out about the rest of the 2,133 bytes
I suppose combining HDMA and CPU writes might work with the stack method, but the timing would be pretty tight, and the recopy gaps would kill the data rate. In any case, HDMA isn't magic; it uses the same I/O ports as manual data, and it takes APU-side processing time to pick it up just like manual data, the only difference being that HDMA doesn't check if the S-SMP is ready before writing data. Since your method would require the S-CPU to stay in a transfer loop anyway, you might as well just do the whole thing manually.

FYI, in d4s' code, the APU-side loop looks like this:

Code: Select all

ReceiveStreamTransferLoop:			;66 cycles per scanline. this loop must be exactly 66 bytes long while looping.
;26 cycles					;59 cycles per scanline left for actual transfer

	movw	ya,$f4				
	push a					;save data on stack cause that's the fastest way possible
	push y
	movw	ya,$f6
	push a
	push y
	
;waste 33 cyles:
;******************************
	mov	a,TempBuffer1			;real snes/bsnes need a total of 33 cycles here
	mov	a,TempBuffer1
	mov	a,TempBuffer1
	mov	a,TempBuffer1
	mov	a,TempBuffer1
	mov	a,TempBuffer1
	mov	a,TempBuffer1
	mov	a,TempBuffer1
	mov	a,TempBuffer1
	mov	a,TempBuffer1
	mov	a,TempBuffer1

;7 cycles when looping back
	dbnz	TempBuffer5,ReceiveStreamTransferLoop
In my code, it looks like this:

Code: Select all

get_data_HDMA:
   mov A, $F4                ; 3 cycles - get byte 0 of the data shot
   mov !buf+X, A             ; 6 cycles - write it to the current buffer position
   mov A, $F5                ; 3 cycles - get byte 1
   mov !(buf+1)+X, A         ; 6 cycles - write it to the current buffer position plus one
   mov A, $F6                ; 3 cycles - get byte 2
   mov !(buf+2)+X, A         ; 6 cycles
   mov A, $F7                ; 3 cycles - get byte 3
   mov !(buf+3)+X, A         ; 6 cycles
   inc X                     ; 2 cycles - increment the current buffer position four times
   inc X                     ; 2 cycles
   inc X                     ; 2 cycles
   inc X                     ; 2 cycles
   cmp (X), (Y)              ; waste 5 cycles
   cmp (X), (Y)              ; waste 5 cycles
   cmp (X), (Y)              ; waste 5 cycles
   dbnz Y, get_data_HDMA     ; 6/4 cycles - repeat for next scanline, or exit if done
; TOTAL:  65 cycles

Code: Select all

; FOR PAL, REPLACE 15-CYCLE TIME DELAY IN DATA PICKUP LOOP WITH:
   mov A, Y      ; 2 cycles
   and #$01      ; 2 cycles
   beq +         ; 4/2 cycles
   cmp A, (X)    ; 0/3 cycles
+  nop           ; 2 cycles
   cmp (X), (Y)  ; 5 cycles
You will note that my code uses a 65.5-cycle loop in PAL mode, vs. d4s using a 66-cycle loop. This is because 66 cycles is slightly longer than an ideal scanline (65.632 cycles PAL, vs. 65.033 NTSC), and since my method picks up the data more slowly, I have less wiggle room than he did, plus I'm hoping to support longer data bursts.
Is there a program out there that will turn a music sample into BRR format, and either back or let you play it
BRRTools.

The encoder has an option for a high-frequency boost prefilter to mitigate the muffling effect from the gaussian interpolation (it's not perfect, but it's fast), and the decoder has an option for simulating said interpolation (though it seems that as designed, it's only accurate for full-rate input; if my Matlab work isn't wrong, resampling changes the frequency response somewhat at the top end. Also, use the latest version; 3.11 had a bug that would muffle the output much more strongly than it should have).

(Just to be extra clear, the gaussian interpolation is unrelated to the BRR codec. They are both operational features of the S-DSP, and thus both have an effect on how the output sounds, but that's the only connection.)
Espozo wrote:Can the S-SMP generate interrupts for the S-CPU?
No.

...

Also note that uncompressed 32 kHz 16-bit stereo is over 7 MB (not Mbit) per minute. Even with BRR it's still above 2 MB per minute. 26 kHz mono BRR is still nearly a megabyte per minute, and stereo does sound better than mono. ROM size limitations are still relevant, unless you're using MSU1 which kinda removes the point of streaming music to the APU in the first place... IMO you'd get much more bang for your buck using the APU the way it was designed to be used, and maybe using streaming to augment its capabilities like Tales of Phantasia, Star Ocean and N-Warp Daisakusen did.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Rate of streaming data to the SPC700?

Post by Drew Sebastino »

93143 wrote:It's actually slower than a tight handshake loop, but it's automatic on the S-CPU side.
So, only slower for the S-SMP side. I really don't care about that, from my understanding, even 1MHz is overkill for just writing a few things to the DSP.
93143 wrote: I'm hoping for 640 bytes (five chunks), which is enough for 32 kHz stereo BRR
And, according to what you said, you'd have 110-160 bytes unused. It could just be for streaming miscellaneous stuff, like maybe if certain sound effects changed throughout the level. Wait though, the SPC700 still needs to do processing unrelated to streaming though, even if it is little.
93143 wrote: Even with BRR it's still above 2 MB per minute. 26 kHz mono BRR is still nearly a megabyte per minute, and stereo does sound better than mono. ROM size limitations are still relevant, unless you're using MSU1 which kinda removes the point of streaming music to the APU in the first place...
Are there no other memory mapper chips that have been made for the SNES? I've never been a fan of the MSU1 audio, because I feel it's not much better than just having an audio port come out of the cartridge slot, even if the DAC gets the information.
93143 wrote:and stereo does sound better than mono.
A little? :lol: (Also, like your choice of music... :roll: )

Yeah though, this has turned into some complex timing mumbo jumbo that I know I'm not yet cut out for. I knew it was stupid to ask this whole thing, but I was curious. I'll probably just end up using someone else's sound engine. :lol:
lidnariq wrote:Individual samples tolerate lossy compression noise a lot better than whole audio streams.
I don't know, this turned out almost perfectly. Maybe it's not a very good song to do a fair comparison though. I used the BRR encoder and decoder on two different tracks (the left and the right) and then put the back together to be stereo.
Eine Kleine Nachtmusik (WAV vs. BRR).zip
(1.55 MiB) Downloaded 318 times
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Rate of streaming data to the SPC700?

Post by 93143 »

Espozo wrote:
93143 wrote: I'm hoping for 640 bytes (five chunks), which is enough for 32 kHz stereo BRR
And, according to what you said, you'd have 110-160 bytes unused.
I think it bears repeating that my code is untested. Don't count your chickens before they hatch...
Wait though, the SPC700 still needs to do processing unrelated to streaming though, even if it is little.
Yeah, that's why I degraded the performance. I was trying to leave enough space in between chunks for the audio engine to go do something else before having to turn around and get ready for the next chunk. Otherwise all other audio processing would have to happen during VBlank, and having everything happen with 16.7 ms granularity could sound bad in some situations.
Are there no other memory mapper chips that have been made for the SNES?
Well, there's the S-DD1, which is supposed to be able to handle 256 MB in theory. In practice, the pinout may be insufficient - it's thought that the real limit was probably no higher than 8 MB.
even if the DAC gets the information.
Oh, no, it bypasses the DAC too. It's purely analog. Almost more like the Voicer-kun than traditional SPC700 audio. The Super Game Boy does the same thing - what you hear is real DMG sound output.
your choice of music
It was the first example that came to mind. The cartridge version used mono; the 64DD expansion (and the official soundtrack CD) used stereo.
I'll probably just end up using someone else's sound engine.
IIRC the version of SNESMod KungFuFurby and Augustus Blackheart are working on offers up to 12 kHz mono streaming for sound effects. It appears to use a high-speed semi-free-running loop (intermittent sync), with manual data feed on the S-CPU side.
I used the BRR encoder and decoder on two different tracks (the left and the right) and then put the back together to be stereo.
Did you forget to pan them? What you've got here is an excellent mono/stereo comparison, but as a result it's hard to hear the difference the BRR makes... at least on my laptop's cheap sound card...
Post Reply