ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
_whitelogger has joined ##yamahasynths
ej5 has quit [Read error: Connection reset by peer]
<Xyz39808>
AY isn't difficult to become comfortable with. It's just the log volume that's a little iffy
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
<superctr>
<Xyz39808> AY isn't difficult to become comfortable with. It's just the log volume that's a little iffy <- SN PSG has that too
<Xyz39808>
:o
<superctr>
and all FM chips have that
<superctr>
on the SN76489 and AY-3-8910, the scale is -2dB per step, on FM chips it's -0.75dB
<ValleyBell>
Didn't the AY use -3db per step?
<ValleyBell>
also log volume is awesome
<ValleyBell>
You can do smooth fade out/in just by adding/subtracting a constant value every few ticks.
<ValleyBell>
The only reason I prefer the SN over the AY is that you can have 3 squares + 1 noise all at once. (even if the noise frequency is limited then)
<superctr>
right, i remembered it as 2dB as MML compilers typically adjust the volume step to make the FM and PSG volume scale appear identical
<superctr>
the datasheet shows 3dB (2 steps halves the volume)
<superctr>
you can have squares and noise active at the same time on the AY too, but it will mask the output rather than accumulating it so it gets a characteristic sound
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<cr1901_modern>
the log stuff bothers me far less than the use of fixed point (but I mean, it was the 80s not like they had much of a choice if they didn't want their chips to become space heaters)
cr1901_modern1 has joined ##yamahasynths
cr1901_modern has quit [Ping timeout: 244 seconds]
<ValleyBell>
I really like fixed point arithmetic. It's a lot more predictable than floating point.
l_oliveira has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
nukeykt has quit [Quit: Page closed]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##yamahasynths
andlabs has quit [Ping timeout: 258 seconds]
<cr1901_modern>
If one was doing a _software_ FM synth (that wasn't meant to be a 100% reproduction of an old chip), I assume doing everything in logspace is kinda irrelevant performance-wise (multiplications are fast on modern CPUs- though division isn't)
<cr1901_modern>
relatively* speaking
<superctr>
if you want to do a software fm synth, consider what you want to target
<cr1901_modern>
Basic Yamaha OPM/N operator, but floating point for this hypothetical example
<superctr>
for a VST you can go full floating point math and prioritize sound quality, for something less powerful like in a sound module / hardware synth you want to prioritize realtime performance
<Wohali>
still easier to do lookup tables for logs
<Wohali>
and faster, generally
<cr1901_modern>
I can always benchmark a few impls too :).
<superctr>
try to benchmark them on a 50mhz arm as well as your 2+ghz x86_64
<superctr>
some things will be much slower on a system without a FPU or even hardware multiply
<Wohali>
^^^
<whitequark>
modern CPUs are so ridiculously fast you probably can write the entire OPM in Python and it'd still be good enough
<Wohali>
get an old 68k mac or something
<superctr>
you won't be able to run a python OPM emulator on a microcontroller or even low spec SoC i think
<whitequark>
of course not, that's kind of my point
<whitequark>
modern CPUs are a bad benchmark precisely because they're so overpowered
<l_oliveira>
a sub 1ghz computer has problems to run games in python (pygame) nowadays
<l_oliveira>
older versions worked
<superctr>
now that plug and play tv systems is all the rage, if you write a proper OPM emulator you'll perhaps want it to be used in an emulator
<superctr>
and if you were making a hardware synth, you'd probably want to break the 8-voice polyphony limit of the original yamaha parts and try to fully utilize your hardware
<whitequark>
that's actually one thing my approach wouldn't deliver
<cr1901_modern>
750 voices w/ Core i7 (I mean, there's a law of diminishing returns for that I think?)
<superctr>
i wonder how many FM voices you can get from an ice40 fpga
<cr1901_modern>
JT51 is a rather large core
<cr1901_modern>
it takes up half an LX9
<whitequark>
superctr: you need how many registers per voice?
<cr1901_modern>
or something
<whitequark>
eight?
<Wohali>
well, there is micropython
<Wohali>
it's pretty awesome
<whitequark>
actually you're probably limited by frequency
<whitequark>
since you have way more block RAM than processing time per voice
<superctr>
i think you have 24 or 28 registers for the voice configuration
<superctr>
you don't need to run your core at the original clock rate either, so you can do lots of register accesses per sample
<whitequark>
right
<whitequark>
so, HX8K has 128 kbit of BRAM, that means at most ~570 voices
<superctr>
the ym2151's total register file is probably about 256 bytes, maybe more considering some are inaccessible (internal EG/PG stuff etc)
<cr1901_modern>
the global data footprint would be amortized by the time you reach 256 voices I think
<whitequark>
EG/PG would probably be a counter in discrete logic
<superctr>
probably
<superctr>
voice registers can fit in block ram, rest would be le registers
andlabs has joined ##yamahasynths
<cr1901_modern>
On a side note I wish libfmsynth discussed how the benchmark was done. I would've probably fed a complete voice with random parameter changes every run to simulate real notes/voices. How many channels max do "real" sampled sound chips have? I think a Namco chip has 24 voices
<superctr>
the C140 has 24 voices but it's at a low sample rate (24khz)
<superctr>
C352 has 32 voices at 88khz (or 44khz, not completely clear) but it was never paired with FM chips.
<cr1901_modern>
Need not be an FM chip in this case
<superctr>
Taito/Zoom ZSG-2 (used in FX-1B and G.NET arcade boards) supports 48 voices, though the real performance killer there is the TMS57002 DSP which it's paired with
<cr1901_modern>
I'm just curious about the practical upper bound before mixing problems happen
<cr1901_modern>
e.g. to mix 48 voices, either divide by 1/48 for each voice, or pray it doesn't overflow a counter and your DAC is up to the task
<superctr>
most PCM sound chips you can saturate with just 2-4 voices
<superctr>
Even the ones with shit ton of voices
<cr1901_modern>
great
<superctr>
Consider that they might be used for streamed audio too
<cr1901_modern>
?
<superctr>
then you'll only have a left and right audio stream which you'll want to play at max volume
<cr1901_modern>
wouldn't that calculation be done after samples have exited the mixer (so it would be scaling by a number < 1 for volumes less than max)?
<superctr>
The mixer can handle saturation
<superctr>
whether volume scaling for a single channel can saturate the mixer depends on the chip
<cr1901_modern>
I don't understand where you're going w/ the streamed audio tangent tho :(
<superctr>
most of the custom PCM chips used in arcade games were designed for sequenced music rather than streamed music
<cr1901_modern>
what's the difference :P?
<superctr>
for sequenced music you have a "soundfont" with one of more samples for each instrument. Sequence processing is handled by a discrete sound CPU in most cases
<superctr>
for streamed music you only have a mono or stereo stream (often but not always ADPCM format) with already mixed and mastered music streamed in the ROM
<superctr>
Most arcade games from the mid/late 90s and on used streams
<superctr>
the YMZ280B and YMZ770 were sound chips specifically designed for that
<cr1901_modern>
Then what's the need for a PCM chip at all for streamed music? "Just" DMA to a DAC at regular intervals?
<superctr>
They handle compression and sometimes sequencing
<cr1901_modern>
hrm
<superctr>
280B used simple ADPCM (same algorithm as the AICA except swapped nibbles) and 770 used a modified MPEG-2 codec called amusement audio or similar
<superctr>
They weren't used for that long, eventually arcade games moved to PC hardware and sound chips became obsolete
<cr1901_modern>
>whether volume scaling for a single channel can saturate <-- I would consider this really bad design btw. But just my opinion
<cr1901_modern>
first of all, if you have a stream that's already been mixed and mastered, what purpose is there to amplify it on its way out?
<superctr>
Nah, it won't clip
* cr1901_modern
is used to sound chips where the samples/input can only be attenuated or unchanged
<cr1901_modern>
Which is I think stuff like the Ricoh PCM chips and the Yamaha FM synths
<superctr>
But it means all bits from the audio will be sent to the MSB of the serial DAC output
<superctr>
as is
<superctr>
Typically PCM chips use a hardware multiplier for the mixing / volume calculation
<cr1901_modern>
> But it means all bits from the audio will be sent to the MSB
<cr1901_modern>
I don't understand... how do you fit "multiple bits" into a single bit :P?
<l_oliveira>
cr1901_modern: YM2608 ADPCM can do both streamed (host CPU sends data periodically to a register, similar to the OKI on the X68000) or automated playback using self controlled DRAM
<superctr>
most significant bits
<superctr>
fuh
<superctr>
duh
<cr1901_modern>
MSBs ;)
<cr1901_modern>
parse fail, but MSB is singular in my head
<l_oliveira>
the RICOH can't do stream can it?
<superctr>
RF5C68 can't stream but the main CPU can access memory while the PCM chip is playing samples
<l_oliveira>
write only, right?
<superctr>
So you can treat it like a FIFO
<superctr>
I think you can read too, but not sure
<l_oliveira>
to read you have to stop it
<superctr>
that makes sense
<l_oliveira>
I think that would be the gotcha
<l_oliveira>
some MEGA-
<superctr>
no need to read during playback though
<l_oliveira>
some MEGA-CD games use that ram as extra storage
<cr1901_modern>
>CPU can access memory while the PCM chip is playing samples
<cr1901_modern>
"Just" never send 0xFF, and the PCM chip will play indefinitely
<cr1901_modern>
?*
<cr1901_modern>
as long as you keep feeding it data?
<superctr>
no, you send FF to make it go back to the loop point
<cr1901_modern>
what's the stop command?
<l_oliveira>
I think that's similar to how the ringbuffer on soundblaster cards worked back then?
<superctr>
it has none
<superctr>
some emulators will stop playback if the loop is "0" bytes but that's really just performance optimization
<l_oliveira>
computer freezes, the card keeps repeating what is on the buffer adnauseum
<cr1901_modern>
Anyways, this is very enlightening. I have basically one more q: How can a mixer handle saturation besides clipping or clamping?
<cr1901_modern>
are there "special tricks" that can be done to make the output still sound good?
<superctr>
not unless you have a readahead buffer and have automatic gain control
<cr1901_modern>
the two work together?
<superctr>
so you can ramp down global volume when you notice saturation ahead of time
<whitequark>
l_oliveira: it still happens today on most sound cards i think
<cr1901_modern>
Oh I can totally confirm it happens today
<l_oliveira>
hehe
<whitequark>
since they still all use ring buffers
<superctr>
i remember it happened as late as on my windows xp pc
<cr1901_modern>
I just absolutely love it when I'm doing hard disk/CPU intensive stuff while watching a video and a small snippet of audio plays ad-nauseum
<superctr>
the HDD was so slow the PC would lock up while the HDD was reading data
<cr1901_modern>
until the system stops f***ing up
<superctr>
and the sound buffer would repeat over and over
<l_oliveira>
On Linux?
<l_oliveira>
Linux and Windows certainly handle these things differently. Windows like to freeze bad when it has problem reaching the swap file, so bad you may even see the mouse pointer freeze
<cr1901_modern>
I'm on Windoze
<l_oliveira>
Linux tend to keep responsive to a extent even if the host disk is failing on you
<whitequark>
i've only seen this on linux during a kernel panic
<cr1901_modern>
My favorite sound f***up is probably GBA... it uses a "ring buffer", but you have to reset the pointer manually after each chunk of data, otherwise the audio subsystem will keep reading on
<cr1901_modern>
It will happily start reading ROM data as samples
<l_oliveira>
but Windows you hardly have chance to save anything if it get to that point
<whitequark>
so it's not a ring buffer?
<whitequark>
just like... a buffer
<superctr>
the GBA's 8-bit DAC is worst
<cr1901_modern>
buffer which you manually reset the head
<whitequark>
that's a regular buffer
<l_oliveira>
it has automated play, right?
<l_oliveira>
one-shot?
<cr1901_modern>
yea, that's why I think it's special
<cr1901_modern>
maybe that distinction is misguided
<superctr>
it's more like a DMA-driven DAC
<cr1901_modern>
if you don't reset the head, you start reading other parts of the memory map
<cr1901_modern>
this is why you hear a very peculiar sound when a GBA game crashes
<superctr>
it has full DMA access to the rest of the system
<l_oliveira>
ring buffer is called that because it automatically wraps around by it's own
<cr1901_modern>
okay, bad terminology :P
<l_oliveira>
it just lets the host know it reached the end by a irq I think on sound cards case
<cr1901_modern>
you could probably get some good glitch samples by reading random ROM cartridges as samples
<l_oliveira>
oh wow it's chiptune asmr
<l_oliveira>
(lol)
<cr1901_modern>
sound chip tan whispers directly into your soul for 45 minutes
<superctr>
reminds me a little of when i was working on my MOD to OPL4 VGM converter
<superctr>
yamaha never said the loop point couldn't be 0 bytes or something
<superctr>
so my VGMs would cause the chip to play the entire sample memory or something
<cr1901_modern>
bahaha
<cr1901_modern>
This reminds me how on Sega CD games (well Sonic CD anyway) you can mount the ISO filesystem, convert *.bnk files to *.wav and then play the entire sample memory (plus the sub-68k program) in VLC
<cr1901_modern>
almost certainly those *.bnk files are raw images similar to the type you get when using objcopy -O binary
<superctr>
well, you can do that too with certain CD players
<superctr>
play the data track as redbook audio
<superctr>
enjoy your ear rape
<superctr>
easiest way though is to dump the cd as bin/cue and open the bin in audacity
<cr1901_modern>
I'm not all that great w/ how redbook works
<superctr>
it's just 16-bit linear pcm
<superctr>
the subtracks may be interleaved depdning on how it was dumped but it's usually not an issue
<cr1901_modern>
I mean the track metadata and sectors (there's 2 layers of sector on a CDROM AIUI)
<cr1901_modern>
(cue/bin copies both levels, but other image formats only copy one layer)
<l_oliveira>
bnk files on sonic-cd are sub cpu programs for playing the ricoh driven synth music, right?
<superctr>
warning track + data track from sorcerian pce
<cr1901_modern>
I was looking into them a few months ago b/c I was curious where a certain sample came from
<l_oliveira>
oh curiosity flag just set on, it does use the ricoh to play the audio from movies?
<cr1901_modern>
No
<cr1901_modern>
Because the PCM files weren't replaced
<cr1901_modern>
but the rest of the audio was for the US release
<superctr>
the mega cd has another sound chip + DAC for redbook audio
<cr1901_modern>
if they were PCM files, they would be the same regardless of region
<superctr>
everything else that's sampled must go through the ricoh
<cr1901_modern>
I'm pretty sure l_oliveira knows that :P
<superctr>
you might be able to write data directly to the redbook dac but it's limited i think (44khz sample rate etc)
<l_oliveira>
movies don't play through the red book audio dac
<l_oliveira>
I was thinking specifically of the sonic cd movies in this case
<cr1901_modern>
superctr: I'm not sure why I thought scrolling the cursor to the middle of that file was a good idea, but I did it
<superctr>
mega cd games that use fmvs can't use redbook
<cr1901_modern>
and I got what I deserved
<superctr>
Usually the FMV contains interleaved sound data which must be played through the ricoh
<l_oliveira>
so any streaming audio which need be played will go through the ricoh, right?
<superctr>
written directly to sample RAM
<superctr>
yeah
<cr1901_modern>
They why did they bother changing out one PCM file but not the rest?
<l_oliveira>
well of course, you need bandwidth for both the video and audio, nas to be in cd-rom mode to get the data, so no red book audio on that case
<cr1901_modern>
>Usually the FMV contains interleaved sound data <-- oh
<l_oliveira>
nas = has*
<superctr>
the "past" stages from sonic cd are sequenced
<superctr>
SoA didn't have the technology to replace the sequenced music :P
<l_oliveira>
which are these bnk files CR mentioned
<l_oliveira>
brb
<cr1901_modern>
>SoA didn't have the technology to replace the sequenced music :P <-- right, and this is the part that makes no f***ing sense to me
<cr1901_modern>
Spencer Nielsen said "politics" was the reason the PCM tracks didn't get redone
<superctr>
they would have had to send midis and samples to japan for SoJ to convert it to SCD's sound driver format
<superctr>
They did that with the Sega CD BIOS though
<superctr>
i guess that was an exception
<superctr>
politics is also why american and european devs never got SMPS which most of the the japanese mega drive games used
<cr1901_modern>
Was there ever a Switching Mode Power Supply dev kit dump?
<superctr>
the sega Pico SDK has a stripped SMPS which was leaked
<cr1901_modern>
that might be even more interesting to me, tbh :P
<superctr>
Actually, Darxide 32X uses a unique SMPS deriative for which we have technical documentation but not the source code itself
<superctr>
that game was developed in europe i think
<cr1901_modern>
would the Pico SMPS be on hidden palace (for my own "archives")?
<superctr>
maybe?
<superctr>
i have it hoarded on my PC, of course
<cr1901_modern>
would you be willing to link to it :3?
<cr1901_modern>
Anyways, if anyone can remember the lone Genesis game that emitted samples on the 68k side (and only for the "developer splash screen"), I'd be appreciative :D
<superctr>
his reaction when a bunch of angry bees steal his hentai magazines
<l_oliveira>
this Apidya game is trying really hard to emulate some neogeo game from Alpha Denshi haha
<l_oliveira>
emulate the style
<l_oliveira>
dat running animation
<l_oliveira>
ok stopping here
<l_oliveira>
and one for manboobs with that armor
<fseidel>
every few months, someone reminds me of the mega turrican intro
<fseidel>
and I get to laugh about it again
<fseidel>
the devus of Apidya pretended to be a Japanese company called "Kaiko" because they wanted people to think it was a high quality Japanese shmup
<fseidel>
A+ for effort
<fseidel>
*devs
<superctr>
at least it WAS higher quality than just about every other european shmup
<fseidel>
yeah, Apidya is actually playable
<fseidel>
they also did an eroge puzzle game under the Kaiko label IIRC
<fseidel>
seems that it was Chris huelsbeck and one of the graphics people at Factor 5, possibly others
<superctr>
i believe the same devs did rendering ranger r2 on snes too
<fseidel>
that game was manfred trenz
<fseidel>
and he had already left factor 5 by the time Turrican 3/MT came out
<fseidel>
IMO, Mega Turrican is the best Euro-platformer ever