-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support the SPC music format #7
Comments
Yup, this should do it: https://github.com/emu-rs/snes-apu However, seems it only compiles for OSX, guess due to missing audio output bindings for the other platforms. There is even an issue about this: emu-rs/emu#6 |
That issue looks like a place where we could help. First we should research whether there are any resamplers now, and if not maybe we should write our own. Maybe some @mitchmindtree @ruuda @yupferris what are your thoughts? |
Sure! I've not ran into any use cases for SPC personally but I'd be happy to see it supported. @est31 It looks like that issue is only related to the audio IO, not the codec itself. emu seems to use the spc crate for spc decoding, which I'm guessing is already portable as it is in pure rust? Re: resampling and the |
The spc crate only decodes the dsp program from the file, but actually get the samples you need to run an emulator. Also, I've looked, seems there is no feature to turn off playback support so that there is no requirement on mac os. Probably something that upstream should pursue either way as the decoders shouldn't pull in os playback api libraries I think :) |
About use cases... I don't have one either, but its one more format we support :) |
hi there! As the author of snes-apu, I'd love to see this integration happen. As for it only compiling for OS X, this is actually not true. The crate itself should compile fine on all platforms; the example only compiles for OS X, as it relies directly on our coreaudio-rs package currently for actual playback. The actual lib code containing the core emulation should be fully cross-platform though (if it's not that's a bigger problem and we need to fix that). As for emu-rs/emu#6, I was kindof waiting around for cpal to incorporate coreaudio-rs again, then was going to add a driver for that there. I also want to redesign the emu audio driver api to be push-based rather than pull-based, and it'd be best to do that before incorporating additional platforms most likely. However, in the context of integrating with this audio library, that stuff shouldn't be necessary for now (however I'd be thrilled if you wanted to take a look at that). Overall though I'm happy to help in any way possible if you're willing to incorporate this package :) |
Additionally for emu/snes-apu etc if relicensing under MIT/apache2 makes things simpler, I'm happy to accept that as well. |
Just did a quick clone/build; snes-apu indeed works fine on Windows (minus the example ofc, which actually needs playback). |
About licensing: BSD like licenses are okay. The only ones I'd avoid for this crate are strong copyleft ones like LGPL or GPL. And for compiling it, I guess you are right. Missed that |
@est31 snes-apu no longer has a dev dependency on |
@yupferris thank you! |
I'll look at doing an |
what do you mean by |
Keep in mind I also haven't done a proper crate version bump+publish yet, as you mentioned you were waiting on a couple things before that. While the current snes-apu API isn't that great, it should definitely do what you need for this use case. If it works for you, I'd recommend implementing support on top of master in these repos, then I can publish new versions when support at this level is ready in case there's any additional changes we need to make. But I don't suspect there will be anything major. |
@yupferris one thing which would be nice to get fixed before this gets included in audrey would be to get rid of |
Recently, there has been a RCE-able c implementation. With all the rust based SNES emulators around, I'm sure there is one that also has support for the SPC music format? It would be great to provide a safe alternative to the dangerous C implementations our users.
The text was updated successfully, but these errors were encountered: