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
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 276 seconds]
ej5 has quit [Quit: Leaving]
<ValleyBell>
andlabs: Do you want to send me a patch for the race condition in CoreAudio? (a git-format-patch thing would be nice) Alternatively you can just make a pull request on GitHub.
Xyz_39808 has joined ##yamahasynths
SceneCAT has joined ##yamahasynths
<andlabs>
not right now; would need to jump through alegal hoop, and also I'm not sure if it ieven is the correct fix
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 245 seconds]
l_oliveira has joined ##yamahasynths
andlabs has joined ##yamahasynths
andlabs has quit [Client Quit]
cr1901 has quit [Quit: Leaving.]
cr1901 has joined ##yamahasynths
ahihi has quit [Quit: make something beautiful]
cr1901 has quit [Quit: Leaving.]
cr1901 has joined ##yamahasynths
andlabs has joined ##yamahasynths
cr1901 has quit [Quit: Leaving.]
cr1901 has joined ##yamahasynths
<ValleyBell>
andlabs: I'm pretty sure that this one mutex around drv->FillBuffer should fix the critical race condition. I put a mutex around it in all other audio drivers as well.
Xyz_39808 has quit [Ping timeout: 276 seconds]
<ValleyBell>
I consider all the race conditions regarding variables in the player classes another problem.
Sarayan has quit [Ping timeout: 257 seconds]
Sarayan has joined ##yamahasynths
<Sarayan>
whitequark, active perchance?
<whitequark>
Sarayan: yea
<Sarayan>
In my infinite todo list, I have "writing a jit", specifically to dynamically generate code for rendering in mame and also has a recompiler backend
<Sarayan>
are there approaches you would recommend?
<whitequark>
not writing a jit
<whitequark>
using existing one
<Sarayan>
I've yet to find one that would match
<whitequark>
sounds difficult then
<whitequark>
i'm not very familiar with jits
<Sarayan>
I understand them as "compilers that don't have that much time for optimizations"
<whitequark>
that's not the distinguishing characteristic of a jit
<whitequark>
i mean
<whitequark>
sometimes you care about latency but sometimes not
<whitequark>
webkit used to use llvm as its 3rd jit
<whitequark>
the two distinguishing characteristics of a jit is "emitting code to memory" (easy mode) and "being able to deoptimize" (hard mode)
<whitequark>
somewhere in between you have inline caches
<Sarayan>
deoptimize?
<whitequark>
well, you optimize with some kind of assumption that makes your life easier, e.g. "this variable doesn't overflow"
<whitequark>
so when it does overflow, you have to backtrack
<Sarayan>
oh
<whitequark>
restore the state that you optimistically optimized out back and such
<Sarayan>
I *may* be able to avoid that kind of considerations
<whitequark>
so you just want a fast templated compiler?
<whitequark>
could rip one out of qemu, maybe
<Sarayan>
kinda yes
<Sarayan>
the #1 optimization I want is actually constant propagation and dead code elimination, plus sane register allocation
<whitequark>
mmm
<whitequark>
that's, to put it mildly, not very easy
<whitequark>
if you want CP (and probably you want SCCP) you need a real IR or at least an approximation of it
<Sarayan>
pretty much yes
<whitequark>
i think most jits these days go with sea-of-nodes
<whitequark>
can propagate constants through loops for example
<Sarayan>
ah nice
<whitequark>
and through conditionals when they turn out to evaluate to the same thing
<whitequark>
it's pretty cheap to compute
<Sarayan>
the idea, really, is that I have a complex code that emulates says a graphics plane mixer, but most of the use of the inner-loop code depends on a mode register that's constant on a given frame (and does not change often in practice)
<whitequark>
so you want to inline it as a constant?
<Sarayan>
pretty much, doing for a specific mode value often drops 70% of the code
<Sarayan>
in the inner screen-sized loop
<Sarayan>
but the mode can easily be 16 bits or more
<whitequark>
ohhh i see
<Sarayan>
so can't sanely pre-generate all of them
<whitequark>
yes, this is actually a pretty reasonable thing to do with a jit
<Sarayan>
I think so
<Sarayan>
I'm always sad there isn't one in the C++ standard for just that
<whitequark>
take a look at gnu lightning
<Sarayan>
runtime-generated templates, kinda
<whitequark>
so metaocaml but for c++
<Sarayan>
gnu lightning? Ok thanks
<whitequark>
no i mean you want metaocaml
<whitequark>
it sounds similar from the description
<whitequark>
you can't actually use it for this task though
<whitequark>
gnu lightning is totally unrelated
<andlabs>
ValleyBell: sure I guess??? I do notice stale buffer data when pausing and unpausing
<andlabs>
so my employer is Google and they have an interesting policy when contributing to open source projects, and I'm not sure where libvgm falls into that, because it happens to contain code from MAME, so if it falls under the class of "video game emulators" I wouldn't be able to contribute the fix *as* Google
<Sarayan>
wq: Guess I'll have to do mine after all :-)
<whitequark>
Sarayan: oh? how so?
Lord_Nightmare has joined ##yamahasynths
<andlabs>
(which doesn't mean I won't be able to contribut;e it just means I have to ask for explicit approval)
<andlabs>
(and ahve to do it on my own time, but I own the copyright so you won't have to credit Google)
<andlabs>
a bit more pressing: I think either the emulator or the Time Trax VGM is busted, because the stage 1 theme loops incorrectly
<andlabs>
lead instrument voices corrupt for a good amount of the loop
<cr1901>
I wonder if metaocaml would be useful for generating a fast ym* implementation. I think a purely functional ym emulator (or close to it) would be useful to be checked against a hardware impl (which is checked against a netlist). Then it could be compiled to something that's well a bit faster. >>
<whitequark>
why not just use verilator
<cr1901>
Would verilator generate code that's fast enough for storing sound into buffers in real time?
<cr1901>
Note: I tried a purely functional single FM _operator_ years ago in Racket and it couldn't meet real time requirements without clipping about 10% of the time
<cr1901>
(only mutable code was, of course, to store stuff into sound buffers b/c at that point I don't give a crap if it's pure :P)
<whitequark>
mhm
<TD-Linux>
someone on twitter was running a gameboy in realtime on verilator
<superctr_>
<andlabs> a bit more pressing: I think either the emulator or the Time Trax VGM is busted, because the stage 1 theme loops incorrectly <- i made my own vgm rips of the time trax music before the pj2612 pack was published
<superctr_>
my tracks are all properly looped, of course
<cr1901>
TD-Linux: Well there goes that theory. Still feels gross, but that's because I have am very sensitive to aesthetics :P
<cr1901>
I am*
<cr1901>
If it can handle a gameboy, then yes it'll handle a synth core I'm guessing
<superctr_>
verilator is quite fast
<superctr_>
it converts verilog code to C++ actually
<superctr_>
and gives you a C++ API for your frontend code
<cr1901>
right, but AFAIK it honors the verilog spec exactly. Which means executing hardware semantics such as propogating values from intermediate wires that aren't relevant in even a cycle-accurate implementation
<whitequark>
metaocaml is not related to anything else whatsoever in this discussion
<whitequark>
and it doesn't do what you want, it's just an interesting direction
<whitequark>
18:12 < whitequark> take a look at gnu lightning
<whitequark>
this *does* what you want
<superctr_>
the speed of your generated C++ code will probably be relative to the complexity of your RTL code
<whitequark>
well, i think it does
<Sarayan>
ahhh ok
<Sarayan>
and mis-associated your statements :-)
<Sarayan>
s/and/I/
<Sarayan>
another independant question. I have schematics, I'd like to turn them into some synthetisable and simulatable HDL, but both verilog and vhdl are horrible. Any suggestions?
<Sarayan>
For things like the wd1772, or eventually the ym2203
<Sarayan>
(well, without the DACs for the 2203, but you get me)
<superctr_>
there are a few languages that compile into verilog/vhdl
<superctr_>
every now and then i stumple upon a project that uses them
<superctr_>
i don't remember the names though...
<whitequark>
Sarayan: well, there's nmigen :p
<Sarayan>
wq: is it appropriate for (hand-)generating from a schemtics?
<whitequark>
sure, why not
<Sarayan>
it seemed to constrain the kind of stuff you could model
<Sarayan>
but I may not have understood the summary
<whitequark>
do you need something more than synchronous logic (in multiple domains, with async resets possibly)?
<Sarayan>
Good question
<Sarayan>
I can't be sure of what will be in a die, but most of what I've encountered tends to be clocked
<Sarayan>
68000 has some analog delays and multiple phases on the clock, but it's really an extreme
<whitequark>
so the thing is, if you have analog delays and multiple phases, it is not simulatable via verilator
<whitequark>
multiple phases might be ok
<whitequark>
but delays will likely not be
<superctr_>
it will be hard to synthesize too
<whitequark>
so i don't know how are you gonna get good performance out of it
<whitequark>
yes also that
<Sarayan>
the wd1772 may have a couple of delays, but I'm not sure how critical they are
<whitequark>
Sarayan: rule of thumb: if you write the netlist such that it works well on an fpga, nmigen will be a very good fit for it
<Sarayan>
yamaha seems to have nothing analog outside of the dacs
<whitequark>
verilator = fpga here
<whitequark>
if you write the netlist so it can be *only* simulated by an evented simulator like icarus verilog, nmigen will not be a good fit
<Sarayan>
well, I want to write the "netlist" to explain/reimplement the chip
<whitequark>
right, that is high level overview
<Sarayan>
I'd like to have it usable as a component in glasgow/mister/whatever
<whitequark>
absolutely do it in nmigen then
<Sarayan>
e.g. turn glasgow into a wd1772 just for kicks
<Sarayan>
or into a 2203 fwiw
<whitequark>
anything you manually decompose those analog components into, will work well in nmigen
<whitequark>
and ice40 doesn't have analog delays so you would have to decompose them
<Sarayan>
wd1772 puts a delay on a couple of signals, I'm not even sure why
<whitequark>
you could always leave an instance of some black box for the analog delay if you want to simulate it separately
<whitequark>
nmigen will not understand the blackbox or be able to synthesize it
<whitequark>
but you could simulate it in iverilog
<Sarayan>
68000 has a bunch of delays, it's more annoying, but I'm in no hurry on that one (and there's a verilog 68000 already anyway)
<Sarayan>
glasgow uses nmigen, right?
<whitequark>
not yet, it uses its predecessor. but i've ported large parts of it to nmigen
<TD-Linux>
usually the solution to chips with internal delays (6502 esp) is just to clock your version twice as fast
<TD-Linux>
fx68k does cycle accurate 68k without higher speed clock tho
<Sarayan>
TD-Linux: the 68000 has a number of delays for signal shaping
<Sarayan>
fx68k is internally rather far from the real 68000 structure
<Sarayan>
I wonder how kevtris did it in his core mind you
<Sarayan>
I'll have to ask him when he's around
<Sarayan>
thanks for all the answers, I'll see if I understand anything about nmigen :-)
<whitequark>
feel free to ask
<Sarayan>
thanks, I will, but I'll start by having a look, seems kinda more productive :-)