Open GoogleCodeExporter opened 9 years ago
Front end accepts only 44.1khz 16 bit, which all of the cores produce directly.
Supporting anything else would be a bit of a project.
Most of the older consoles produce audio directly at very high frequencies
(1MHZ+). In most cases, it's sampled down using blargg's blip buffer. You can
find out more about the theory and practice of that here:
https://code.google.com/p/blip-buf/
http://www.slack.net/~ant/libs/audio.html#Blip_Buffer
https://code.google.com/p/blip-buffer/
In my mind, the highest priority thing for AVI output would be to get rid of
that damn timestretcher (dup\drop worthless video frames instead).
Original comment by goyu...@gmail.com
on 10 Oct 2014 at 1:22
Oh, that's to bad. As it resamples everything as i don't think consoles use
44.1, but 48 (if they even are their, most are probably at 32 or below).
And of course as you say, those that create their own sound, that's another
story and resampling there is a must either way.
But well how does the timestretcher currently work, cause i notice that the FPS
is not 60 for me, it's above.
This tends to happen when allowing a master stream of Audio control the Video,
so the FPS will increase/decrease in order to fit the Audio. This happens only
if Video and Audio follow 2 different clocks.
Original comment by 24levit...@gmail.com
on 10 Oct 2014 at 1:53
As I said, many of the consoles we emulate natively produce audio at rates much
higher than 48khz, often times 1mhz or higher. Other consoles like the genesis
involve multiple chips at different frequencies that are mixed in analog, so it
has to be resampled immediately anyway. The only consoles I can think of
offhand that support a native 48khz output are a gamecube\wii and a ps2. On
the other hand, the ps1 and the PCE support native 44.1khz output.
The timestretcher works by dumping video at its stated rate and then stretching
audio to match. How much of a change that makes depends on the console; some
of ours produce more accurate audio than others.
Original comment by goyu...@gmail.com
on 10 Oct 2014 at 3:49
Thought the N64 did that, guess it resampled to that as it's the TV standard
then.
Yeah Gamecube PS2 etc had a DAC and files that were all 48khz i guess. So
pretty much like CDs are 44.1khz.
Hmm, i see thought it acted like Directhow capturing would.
But yeah well Audio is never in sync with the PC (Video in this case) cause
they have 2 different clocks, it's impossible for them to be in sync and keep
the same pace. You either stretch or change the pace.
So how are you wanting to tackle that?
There are many ways, Sync to PC, Sync to Audio, Dynamically Resample Audio to
Fit the PC.
I would say Syncing to the PC is the most correct way in terms of you playing
it. as 1000 seconds on your PC may be 999 seconds to your Audio.
And that's what you currently do.
As for making that at a rate of 60fps (or whatever) instead of "nearly 60fps",
you would need to simply pour frames into the file and have some kind of check
on them.
So if it looks at the PC Timer and it says 0.900 seconds has passed and you
have 59 frames, you would be getting to many frames, so you let it hit 60 and
skipp the rest till the Timer Resets(goes to the next second).
If it's to low, you of course duplicate.
But you have to keep track on the frames, as they don't fit into the figure at
all times, as you can be behind with 3.53 frames, so you have to keep track on
that, and when it reaches and Int (4 in this case) you add/skip 4 frames
(Though it would probably always be at 1 as you don't really need to wait on
several frames).
Still i guess that's what you are trying to do. And it's easier said then done.
I only knows how to Sync audio to the PC by discarding/adding data during
recording, and Stretching is better for that (If of course it can keep track if
Audio really gets missing cause of CPU load and can fill that gap, else it will
go way off).
How do you Stretch if i may ask, i am guessing dynamic resampling, as you can't
mean stretching afterwards and you can also not mean a dynamic samplerate (like
a dynamic fps that changes to fit what it's at) as sample rates are far off to
be good at that as it doesn't work with Float.
Damn much text of waste there, sorry and Thanks;)
Original comment by 24levit...@gmail.com
on 10 Oct 2014 at 7:49
N64 is programmable adjustable sound rate I think, although I'm not sure of
that one.
The AVI writer only has to worry about discrepancies between the emulated
core's sound and video clocks, thankfully; it doesn't need to worry about
realtime problems.
Anyway, I'm filing this whole audio upgrade thing as low priority enhancement.
Original comment by goyu...@gmail.com
on 10 Oct 2014 at 1:38
Okay thanks for having it in your mind:)
Original comment by 24levit...@gmail.com
on 10 Oct 2014 at 3:08
As an experimental option, I've added the ability to dump avi without
stretching audio (video is stretched instead). Support for anything other than
44.1khz isn't any time soon though.
Original comment by goyu...@gmail.com
on 11 Oct 2014 at 5:54
Interesting, will try it out when i find a build later;)
Thanks
Original comment by 24levit...@gmail.com
on 11 Oct 2014 at 8:40
Original issue reported on code.google.com by
24levit...@gmail.com
on 9 Oct 2014 at 1:50