Why don't ren'py use pygame.mixer?

[akakyouryuu]

I tried to add ren'py the function that plays music from a certain position and found ren'py doesn't use pygame.mixer, but use sdl directly.
What is the reason not to use pygame.mixer or sdl_mixer?

[PyTom]

SDL_Mixer doesn't support the types of sound files we want to support on multiple channels. This was especially true in the past, when WAVs were the only supported format. Writing our own code also allows for us to seamlessly switch between multiple segments of a song.

[akakyouryuu]

OK. I will try to do by ffmpeg.
I found av_seek_frame at 1427 in ffdecode.c, but I was unable to find that int64_t start_time was changed since it had been declared at 200 in that file. What case is this code executed in?

[PyTom]

OK. I will try to do by ffmpeg.
I found av_seek_frame at 1427 in ffdecode.c, but I was unable to find that int64_t start_time was changed since it had been declared at 200 in that file. What case is this code executed in?

It likely isn't executed - the ffdecode.c code was derived from ffplay, which had some functionality (keyboard-based seeking, subtitles, etc) that Ren'Py doesn't take advantage of.

My current thinking is that I'd be unlikely to merge a music-seeking patch with Ren'Py, as it would also need to be ported to Android (which uses a totally different playback system), and it doesn't really add much functionality over cutting a track up into chunks, and playing/queueing those chunks.

Do you have a use case that needs seeking?

[akakyouryuu]

I wanted to add a MusicRoom a seek bar like below.



It can show the current position, but can't change the position by the bar.
I doesn't pull request this if that lets ren'py to lose the compatibility for android.