Zerosquare, on Mon Apr 18, 2011 3:32 PM, said:
kool kitty89, on Mon Apr 18, 2011 1:47 AM, said:
Oh, wow, I hadn't realized there was no DMA support at all (...) That would add a lot of unnecessary overhead on the DSP compared to hardware buffered playback. (why not implement a simple DMA circuit?)
Yes, I don't understand why they didn't include DMA (which even the Atari STE supported), or at the very least some kind of FIFO queue. The audio hardware is certainly disappointing from this point of view.
Yea, but at least software PCM management wouldn't take up that much DSP time, at least if it was done with some tight looping code (not interrupts, unless the J-RISCs can manage really fast ints -like 650x or 680x).
kool kitty89, on Mon Apr 18, 2011 1:47 AM, said:
Also, I thought the PWM DACs in the Jaguar were configured as 14-bit stereo supporting up to 207.8 kHz (implemented as 4 PWM registers at 26.6 MHz configured as 7-bit linear DACs and paired for 1L and 1R 14-bit channel at 207.8 kHz), though I'm not sure why they wouldn't have configured them as 4 8-bit linear DACs paired for 103.9 kHz 16-bit stereo instead.
The PWM DACs are in the Jaguar chipset, but they're not actually used on the Jaguar console (there's nothing connected to their outputs). Sound is generated by a separate 16-bit, stereo D/A audio converter, which gets its data from Jerry through an I2S serial interface. (I don't know why they did that ; maybe the PWM DACs weren't working correctly.)
That's really weird, though it would explain why there was no DMA support. (I'd gotten the impression the PWM DACs did have DMA, but maybe those don't either)
Then there's also the way they sort of forced digital audio output in the system when it really wasn't needed, that complicated use of red book audio to an unnecessary degree. (if it was plain analog mixing to the Jaguar DAC output, you could have had red book sound with zero hit to the jaguar bus/DSP, but as it is, they had to stream digital data to the DSP, so it wasn't nearly as useful -imagine if the Mega CD had been forced to do that
Digital audio would have been a good feature for provisions to be used in other applications (workstations, etc), but the console probably could have dropped that entirely. (in terms of actually being connected on the PCB)
That's why some games used FM sounds : FM music data is often small enough to fit into the DSP RAM completely, and FM synthesis doesn't need sample data, so the main bus isn't used and thus free for other processors to use.
And you have the 4k wave ROM for other synth techniques (or to use for FM operations -rather than just using sine), but that took more skill and tool support than most developers were working with. (of course, you could also do simple "chip" synth using the wave ROM samples, and a few games seem to use that -though they could be MOD too, just like some Amiga "chip" synth sounds used AHX, but others used plain MOD)
Which games used FM BTW? (Supercross 3D sort of sounds like it, but I don't remember anything else doing that)
Also, a decent sample sound engine wouldn't need to take up a lot of main bus time either, even with the 8.8 MB/s bandwidth limit. You'd just have to limit the bitrate of the samples used (compression would be doubling important there to allow less ROM/RAM space to be used in general). Focusing in 2-bit ADPCM (maybe 1-bit CVSD for some things) could have been a pretty good option for that while allowing decent sample rates in general. (you'd also want to use the scratchpad for the mixing buffer for those samples -to avoid more hits to main RAM and also avoid the 16-bit write bugs JERRY suffers from)
That way, if you used 22 kHz 2-bit samples (5.5 kB/s), you could manage a 32 channel sample engine with only about 2% of the main bus time (or 3% if using ROM directly). Of course, you could use 11 kHz 4-bit ADPCM for the same bandwidth (if interpolated, it might sound better than 22 kHz 2-bit), or just plain 8-bit PCM at limited sample rates using interpolation/filtering to reduce aliasing. (or even 4-bit linear PCM -quite a few cases where well optimized 4-bit PCM will sound better than 8-bit at the same bitrate -ie 1/2 the sample rate)
You could also push a mix of different sample formats if you were willing to deal with the added complexity. (more so if you opted to push realtime synth on top of sample based stuff)
Of course, you could also do a plain 8-16 channel sample system for significantly less bandwdith, but retain the use of compression/interpolation (possibly reverb effects) to go well beyond simple MOD stuff. (many common sample trackers were still only pushing up to 8 channels at the time, so one reasonable option for average developers would be to use up to 8 channels for music and a few more dedicated to SFX -implemented compression rather than plain 8-bit PCM shouldn't have been a huge step either, interpolation/digital filtering support probably wouldn't have been either -of course, if Atari supported tools from that in an SDK, or at least example code for such, that would have made things easier)
Stefan_L, on Mon Apr 18, 2011 9:25 AM, said:
I been wondering about the Jaguar sound capabilities a long time but never found any real answer on the net, for other systems you get very detailed info... like for Playstation(1) it has 24channels DSP effects like reverb and so on... but no info about the Jaguar?
Is the Jaguar only having like the Atari STE 2-channels in stereo? and if more channels would be needed then it would take away processortime for the graphics?
If it is like this then the Jaguar is having very weak sound capabilities :-/
There's no hard limit at all, it's just plain stereo DACs for the output (apparently even simpler than the STe in some respects -no DMA), but with a powerful coprocessor driving audio and giving tons of options and flexibility for sound.
That could include surround sound, interpolation, decompression, reverb (echo) effects, etc, etc.
It's more like the GBA, N64 or 32x in that respect, no fixed audio hardware other than simple DAC output (32x has both FIFO and DMA support though, I think GBA is the same -definitely DMA, not positive on the N64) with sound driven by the CPUs and/or RSP in the N64's case.
Most games used very basic Amiga-like MOD player music/sound (some doing 8 channels at least . . .). There was little use of the DSP for realtime synth (additive, FM, subtractive, etc) or for complex sample based sound in the 32 channel range (let alone interpolation, reverb, etc -I think some MOD stuff used compression, at least).
Another nice thing about that flexibility is no hard limit on compression: you could use one of the "conventional" 4-bit ADPCM schemes, 2-bit ADPCM, 1-bit CVSD, or a custom format (possibly derived from one of those -like 2-bit CVSD).
Ironically, the Sega Saturn's audio DSP wasn't useful for decompression or a couple other features that would have been really useful (it was pretty much never used with the plain 32 DMA sound channels being used directly); the 68k could do it in software, but not fast enough to drive more than a few of those channels at once. (I think the DSP intended for 3D math coprocessing might actually have been more useful for some of those things than the dedicated audio DSP
-the SH2s definitely were)
Even the specs for Atari Panther states 32-channels using Ensoniqe (ES5505) soundchip.
I asked about this before, and apparently, that was only an early plan (to use OTIS); the option was kept open, but all the early development documentation released was apparently aimed FM synthesis. (so Atari was probably planning on using a common Yamaha synth chip -lots of options for that, no idea which chip they were aiming at) Not sure if there was any DMA sound support either)
There's also mention of the dev units using the Ensoniq DOCII sound chip (presumably a direct derivative of the DOC used in the Mirage and Apple IIGS), so maybe that was what was intended for FM synthesis. (I think the way the oscillators are configured, it can be used for FM in addition to wavetable -real wavetable- and sample based synth, but I'm not positive -that would be rather wasteful compared to using a dedicated Yamaha FM chip though; STe style DMA sound driven by the 68k probably would have been fine for the time, or at least if the 68k+sound+I/O stuff was moved to a separate bus from the video stuff -apparently they already had provisions for dedicated audio RAM, so putting the 68k+DMA sound on that bus would have been interesting -one of the main problems with the panther is heavy bus contention and limited RAM due to the high cost of the fast 32-bit SRAM being used -the Panther processor needed it, the 68k/sound would have been fine with commodity DRAM -the panther still wasn't a very well suited design for the market at the time though, especially odd when Atari had the much better Lynx chipset to work with)
philipj, on Mon Apr 18, 2011 12:15 PM, said:
I believe it all depends on how you program the RISC... A while back I began to roughly compare the Jag RISC with the Super Nintendo DSP and found that the Jag is well capable thus have the potential to produce sounds that's better than the SNES sound chip if programmed correctly. There are some limitations like the 8kb of internal RAM in the Jags RISC sound chip compared to what the SNES is 64kb of audio RAM, but that little technicality can be overcome.
The SNES sound system was also sorely underutilized due to the needs of the market at the time (the sound system being WAY overkill) and the tools/interface prvided for programmers to use.
By default, the SNES uses 8 channels sampling to 32 kHz with interpolation (forced, unfortunately) and a 4x echo buffer for reverb. That's technically 32 discrete sound channels the DSP is mixing with most being slaved for reverb effects. Thus, if a better tools set had been implemented, you could have had developers with the freedom to disable reverb and have 4 channels (with no reverb) in place of that 1. (there are homebrew demos that do just that -write directly to the echo buffer to allow up to 32 channels)
There's also the interpolation and BRR sample format, but I'm not sure if those are hardcoded or not, but that would be great to be able to change as wel. (ie if the DSP/SPC700 could be programmed to disable interpolation or use other compression format -or uncompressed PCM, especially since optimized uncompressed 4-bit PCM actually sounds better than BRR/ADPCM at low sample rates, and is a slightly lower bitrate than BRR, though the same as true 4-bit ADPCM-)
As it was, any of that would really have been overkill anyway and the much cheaper 8 channel Ricon PCM chip (FM Towns, arcade, Sega CD, etc) would have been about as good for most things (if not better in some cases). Especially ironic since Ricoh was Nintendo's prime chip vendor already.
I think the only reason most Jag games uses only 8 channels of sound (4 channels for music and 4 channels for sound fx) is because of the limited amount of internal RAM and this is just an assumption; I don't have proof to prove it, but all avenues of information seem to point to that conclusion...
Not really, there's tons of cases where you'd want many more channels in spite of limited RAM/ROM to use. You do have a LOT more RAM to work with in general though: the 8k scratchpad is just forfast code and data (could also be used to mix samples to before outputting to the DACs) while all the samples are stored in main RAM and/or cart ROM (be it uncomprssed PCM, or any number of compression formats). So you have a LOT more to work with than the SNES in that respect; albeit, the SNES can have samples updated on the fly from ROM/main RAM. (if it had been allowed to read directly from ROM, it would have been FAR more flexible -and cheaper too, since you could cut out the 64k SRAM/PSRAM -maybe just 8k or such for SPC work RAM, unless it's already got work RAM on-chip)
You don't use the 8k of SRAM in the Genesis for samples either (aside from a few very limited cases of small sampled crammed into Z80 RAM), but instead have the Z80 pull samples from ROM directly. (which it accesses in 32k banks, unfortunately with a very cumbersome serial shift register making a lot of overhead to switch banks -especially problematic for streaming multiple samples as you'd be switching banks very often -buffing chunks of the samples into SRAM would cut out a fair amount of that overhead though, and also address bus contenton issues for ROM -68k isn't a problem, but the VDP asserting DMA is)
Anyway, the main reason no developers pushed massive sample based sound engines (or few to none pushing realtime synth for that matter), was simply due to the developers Atari was working with and the budgets as well. Amiga MOD was a very common and easy to work with format, that's also why the SNES was often used as a glorified 8 channel MOD player with compression and filtering/interpolation -the latter being a double edged sword).
If you'd had really heavy hitting developers pushing the system's audio, you'd probably have stuff that beat the Saturn's realtime sample/synth stuff (or PSX for that matter).
That's not the same problem the 32x had . . . Sega likely would have pushed the PWM sound a lot further (even in the limited time it was supported) had it not been for one major issue: lack of documentation for the DMA sound feature. Without that, you're limited to using the FIFO buffers or just doing plain interrupt/software times playback with the CPUs. The main reason for that is that the pre-release dev systems were buggy and couldn't use the DMA feature, but all commercial consoles worked (they just failed to update the tools in late 1994, or even '95).
With the slave SH2 dedicated to audio and using DMA, the 32x could reasonably manage 32-64 channels mixed at 22 kHz (more variables depending whether you're pushing compression, other effects, of if you bumped it to 44 kHz).
That's actually a pretty good use for the slave CPU given the bus contention issues (sound processing being very computationally intensive, but bandwidth light), though things like 3D calculations would also fall into that category in some cases.
The 32x's PWM also is configured in such a way that you can increase the max sample rate by dropping the resolution: it's at 23.01 MHz and you could use any combination of sample rate/resolution based on that. The common one to use is ~22 kHz, which gives 10 bit resolution output (23010/1024= 22.47), but you could opt for ~44 kHz audio at 9-bit output (actually 44.94 kHz), or 89.88 kHz with 8-bit output. You wouldn't want to push 11 bit at 11 kHz though, as anything below ~14 kHz has PWM squeal problems. (anything below 14 kHz should be scaled and output to PWM at a higher rate, albeit I think that's also avoided if you use interleave/multiplex type mixing -outputing 1 sample after the other to a sample rate several times higher than the individual "channels" rather than adding them -that could be especially useful if you wanted to use uncompressed 8-bit PCM with minimal overhead; just use 89.88 kHz playback with 6 ~15 kHz channels interleaved, or 4 22 kHz channels, etc -that's channels per L/R stereo, so you could use that as a single bank of stereo channels, or 2 banks of hardwired left/right channels like the Amiga -that sort of mixing is also especially attractive on the Atari STe given the limit of 8-bit resolution output, but pretty high 50 KHz max sample rate -so you could interleave 2 25 kHz channels left/right or 3 16.67 kHz channels, 4 12.5 kHz, etc, etc -no resolution loss from adding, and no overhead dealing with overflow of the limited output resolution)
It's all theoretical at this point. The Jag RISC do have access to the Jags main memory, it would only be a matter figuring out how data will flow from a cartridge of CD.
Most/all sound engines on the Jag use main memory. (Flare had intended use of realtime synth -via FM and/or othr techniques using the 4k wave ROM on-chip and allow it to stay off the main bus almost 100% of the time, but I don't think anyone took that route at all -sort of the same thing with the Slipstream/MS, they had intended a lot of realtime synth and FM was demonstrated in the dev tools provided by Attention to Detail, but then you hear complains about running out of RAM with sound samples -even one mention of "FM synthesis" taking up too much memory -I'm almost positive that was referring to sampled FM instruments and not realtime FM)
The Jag sound chip is generic by nature thus can do whatever you program it to do. In a sense, the same can be said about the Atari Lynx; if it can playback pre-recorded audio, it certainly has the potential to manipulate it audio the way a mod player does. And let's not forget that the Jag can do sound sythesis if you're willing to put in the time squeeze out good sounds. I think the it can produce even more sound channels then a mod player if you use full synth sounds. The Jag sound capabilities is a wide open canvas to explore for anyone that's willing to put in the time.
It should be very capable of sample based synth well beyond MOD, but that was far and away from common tools being used to develop for the system in most cases.
The most common >8 channel smple format was General MIDI's 24 channels, so a MIDI driver on the DSP would have been the most realistic for getting support (not sure if Jag Doom does that or not).
I seem to recall that Atari had actually supported a general MIDI driver for the Jag, but I'm not sure on the specifics.
Realtime synth is generally much MORE intensive than simple sample based stuff. (also, very small/short looping samples use a LOT more resource than long samples -the Amiga would have a hell of a time trying to do what the PC Engine does with the 32 word long looping samples it pushes in hardware, but long samples don't use much CPU time at all by comparison)
You can pretty easily manage a software MOD player on a 8 MHz 68000, but don't even think about trying to push realtime FM synth.
Edited by kool kitty89, Mon Apr 18, 2011 4:14 PM.