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>
oh, I see what's going on - struct mCore is of different sizes...
<andlabs>
I forgot to build mGBA itself with the ocrrect MINIMAL_CORE setting
<andlabs>
yeah it works now; I'm dumb, sorry ^^;
<andlabs>
well mostly works
<andlabs>
it's playing extremely fast and I'm not sure why
<andlabs>
oh shit it's 9:13 PM how the fuck
<andlabs>
afk
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<TD-Linux>
so TXB* level translators are confirmed cursed, but what about LSF*/TXS* ones? this is for open collector isa signals
Xyz_39808 has joined ##yamahasynths
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
ej5 has quit [Read error: Connection reset by peer]
Xyz_39808 has joined ##yamahasynths
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined ##yamahasynths
<Sarayan>
hmmm, if I want to do that sanely, I need to do some work on sview
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 248 seconds]
andlabs has joined ##yamahasynths
<andlabs>
hey kode54 how does foobar2000 do timing? I'm getting audio that's either too fast, choppy, or both with foo_input_gsf just running a constant while samples != 0 runFrame/runLoop/step loop
<kode54>
you first have to configure the blip buffers to the correct sample rate
<kode54>
then you have to frame advance them with the emulator
<kode54>
there are two calls for the emulator, one that takes the buffers, and one that emits just samples
<andlabs>
I haven't tocuhed that code
<kode54>
the way I do it, there's a: _gsf_postAudioBuffer callback
<kode54>
that produces 2048 samples per call
<andlabs>
oh
<andlabs>
oh I get it now
<andlabs>
okay so I take it that code cannot handle variable buffer sizes then
<kode54>
I do that here
<kode54>
core->setAudioBufferSize(core, 2048);
<kode54>
that callback is called on a fixed interval
<andlabs>
yeah
<kode54>
there's also an API for calling for individual samples, but I don't know how that one handles mixing
<andlabs>
and I changed that callback to only fill the amount of the buffer that I actually CAN fill
<kode54>
ah
<kode54>
you should have at least an extra buffer of the size you request
<kode54>
if you make the buffer at least as large as a single frame, it will never buffer more than once per frame call
<andlabs>
now I'm assuming that if you request ofr fewer than the number of available bytes from the blip library, it will keep the remaining bytes around
<andlabs>
is that assumption wrong?
<kode54>
it will, but only to a point
<kode54>
it only has enough room for however much sample data you create the buffer to contain
<andlabs>
ok
<andlabs>
so in that case I should just copy out the extra
<andlabs>
and fill it on the next run
<kode54>
if you request less one frame, you'll have to request more later
<andlabs>
because I'm not in control of how much data Core Audio asks me for =P
<kode54>
try doing it like I do, 2048 samples, loop frames to fill it, and only fill it if it's not already full since the last call or you need more
<kode54>
on next coreaudio call, you can use pre-buffered samples at first, then render another 2048 in loop if you need more
<andlabs>
psf.cpp:336:33: error: assigning to 'int16_t *' (aka 'short *') from
<andlabs>
incompatible type 'void'
<andlabs>
state->active = state->pending.pop();
<andlabs>
can someone please explain the desing of the STL to me