I've finished a minimal band-limited synthesis library for use in sound chip emulation:
blip-1.0.0.zip
It's in C and much simpler than my older Blip_Buffer library. It includes documentation and some demos, including one that emulates NES-like sound hardware and plays back a log of sound writes to it. I think it really simplifies writing a sound chip emulator, allowing focus on the essential aspects, without getting bogged down in resampling output for the PC's lower sample rate.
I'm most interested in feedback on how easy it is to use. Thanks.
*BUMP*
This seems to be interesting. From what I've read in the provided docs, it seems that this can work with existing sound chip emulators. For example, I need to run my emulator at native rate (lets say its at 3.58 MHz) and then just feed the output from it to this blip library and then get the output, right?
blargg, I have a semi-related question. With all the libraries and sound engine work you've done, are there any plans to create a Winamp plugin that uses your engine(s)?
At present, the only thing that really suffices is Notso Fatso, which Disch (respectfully) doesn't maintain any more.
There's a couple folks I know personally who watch your libraries and sound work, but always ask "why hasn't someone made a Winamp plugin using his stuff? Or replaced the sound engine in Notso Fatso with blargg's stuff?"
koitsu, I think Mudlord made a GME-based Winamp plugin at some point. At some point I'm going to finish an upgrade to GME, that among other things brings support for all NSF sound chips, and has a very flexible mixer that should satisfy those who like NotSoFatso's flexible one.
Alpha Dog, yes, using this is quite simple. You could just feed it a 3.58 MHz stream, but the best way is to alter your sound code (much more efficient and simpler to work with too). If you need more assistance, post here or e-mail me. It's useful to me to know what parts are tricky.
blargg wrote:
koitsu, I think Mudlord made a GME-based Winamp plugin at some point.
Yes, and it sounds great...but you have to change tracks via the file information dialog, which isn't updated when you load a new file (you have to close and re-open it, which gets tedious REALLY fast).
There seem to be very few input plugins that have both a usable interface
and high accuracy...
Quote:
Alpha Dog, yes, using this is quite simple. You could just feed it a 3.58 MHz stream, but the best way is to alter your sound code (much more efficient and simpler to work with too). If you need more assistance, post here or e-mail me. It's useful to me to know what parts are tricky.
By this, I assume you mean that instead of copying the buffer into blip, I alter the emulator and generate the sound directly in blip?
Right, generate directly with blip. Using this approach, you only call the library where your waveform changes. This is much faster than generating millions of samples per second then going back and scanning those in a loop and calling the library wherever there's a delta. But it might be a useful exercise to code both ways and compare performance and code readability. I've found that the latter is more complex, because you have to keep track of the buffer position for each waveform, etc.
Another thing, when to do end_frame? Should I do it when a read/write to chip occurs and I am generating some samples in the sound buffer? or Should I set a point to do it (like at the end of a scanline or frame)?
blargg, the link is broken
Can I use it on my emu?
Add this line to your hosts file, as the DNS information doesn't seem to be propagating from ripway.com's DNS servers to your ISP's. (Not working here either. And I get a shitty "this domain doesn't resolve" Yahoo search page from my ISP. Yay.)
Code:
64.62.181.46 h1.ripway.com
Argh, here's the source on a different server:
blip-1.0.0.zip
I fixed some formatting issues in the documentation, which screwed up all the waveform diagrams. That should help comprehension...
polaco, sure, it's here to use in emulators.
Alpha Dog, do end_frame whenever you want to bump the time units back down to zero. If you keep track of clocks elapsed since the beginning of the frame, then ending the sound's time frame at the same time as the video frame makes most sense. If instead you only keep track of how many clocks since the last read/write to sound registers, you could treat each of those as a time frame. With the fixed diagrams, blip.txt should do a better job explaining this. I wish I could better explain the concept. I've tried for years but haven't come up with a really clear way to put it.
Thank you blargg. I can't think of any more questions right now and will be giving this a try and will get back with results/problems (if any
).
Thanks blargg, this looks really cool and useful.
Thanks blargg, it works fine!
my emu finally has sound