Skip to content
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

SDL2_audio overhaul #646

Open
Cobrand opened this issue Apr 23, 2017 · 1 comment
Open

SDL2_audio overhaul #646

Cobrand opened this issue Apr 23, 2017 · 1 comment
Assignees
Milestone

Comments

@Cobrand
Copy link
Member

Cobrand commented Apr 23, 2017

With the arrival of capture devices in SDL2, I've had a look at the current code to see how it works, and we can say for sure that parts of the code aren't really pretty. Adding a capture device will break the API anyway, so maybe we can take advantage of this breaking change to make this API enjoyable to use and safer as well. I've noticed several uses of mem::transmute and mem::replace within the API, and they can almost always be replaced by "safe" code like Box::into_raw. I feel like the API is not Rust-y enough.
For instance, having an AudioCVT in C makes sense, but in Rust we have so many other ways to avoid that.

SDL2_mixer also has its problem with unsoundness and needlessly public struct elements, but we can get on to that later.

@Cobrand Cobrand self-assigned this Apr 23, 2017
@Cobrand
Copy link
Member Author

Cobrand commented Apr 24, 2017

We may even want to merge SDL_mixer into "audio" directly. SDL_Mixer replaces several SDL_Audio* functions from SDL2, see here. The full list :

  • SDL_OpenAudio -> Mix_OpenAudio
  • SDL_CloseAudio -> Mix_CloseAudio
  • SDL_PauseAudio -> Mix_Pause, Mix_PauseMusic, Mix_Resume and Mix_ResumeMusic
  • SDL_LockAudio, SDL_ResumeAudio -> Should not be used

Basically almost 100% of SDL2::audio should not be used if SDL2_mixer is used, functions listing drivers aside.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant