Madplay Under Gmenu2x

[Feeg]

I've got a couple of scripts, one starts madplay in the background, playing my mp3s on a random playlist, the other kills all the madplay processes so I can stop the music whenever I need to.

Unfortunately, any time I'm playing music and open an application, when I return to the menu the music seems to change speed slightly. I suspect it's a problem with the clockrate getting set up and then down again.

Does anyone have any suggestions for dealing with this?

Maybe it would be nice if there was an option to disable clock speed settings temporarily under Gmenu2x to keep it from playing with the frequency when background apps are running. Just a thought.

 

[ryosaeba]

Change the clock in the options (START button)...

 

[Feeg]

Funnily enough that's what I attempted immediately after noticing the weirdness... I don't see an option in that options screen to disable frequency changing.

Does the menu still call the clockspeed setting routine when an application returns to the menu, even if it should already be running at that same speed? Does that routine store or check the last selected frequency to avoid calling it unnecessarily?

I'm getting a strange effect that I assume is related to frequency changing, even when, for example, everything is set to 200mhz.

 

[ryosaeba]

Yes, the clockspeed is beeing changed always, 'cause it may need to reset the overclock used with some emu and I actually don't read the clock value to check if it needs to be changed.

 

[Feeg]

Right, that's what I figured.

So, is it possible to include an option to toggle this behaviour? Useful as it is, it's making background MP3 playback weird.

/edit

or, alternatively, as per the original post, can someone suggest a workaround?

 

[Feeg]

I checked out the source via SVN and I've added a frequency lock of my own, an easy modification- your code is nice to work with Ryo.

Unfortunately running at higher frequencies makes the menu flicker like a bastard. I guess a framerate limit might be a good idea, at least when running at higher frequencies and I'll look into it if I have time.

Strangeness when I compile my own version from SVN though, the shoulder buttons seem to scroll in the opposite directions to what they're supposed to!

Never mind, another easy fix for my personal copy, when I get a chance anyway. Let me know if you want me to check in the changes I made.

 

[ryosaeba]

I checked out the source via SVN and I've added a frequency lock of my own, an easy modification- your code is nice to work with Ryo.

Thanks.

Unfortunately running at higher frequencies makes the menu flicker like a bastard. I guess a framerate limit might be a good idea, at least when running at higher frequencies and I'll look into it if I have time.

I seem to remember someone mentioning that it's an issue related to the paeryn sdl.

Strangeness when I compile my own version from SVN though, the shoulder buttons seem to scroll in the opposite directions to what they're supposed to!

It's a bug in earlier releases of paeryn sdl, if you use the release with 16M of upper memory enabled (you'll find the link in the wiki) the buttons are right.
Of course you could just edit gp2x.h and reverse them. (also note that X and Y are also swapped in that release)

 

[Feeg]

What toolchain do you work with?

 

[ryosaeba]

ooPo's toolkit. I had to modify some Makefile to get it to build till the end though...

 

[Feeg]

Hm, odd. I'm using ooPo's chain too, and updated to the latest version of Paeryn's SDL via version control, yet I still get the odd button swapping. Menu flickering seems to be fixed though, and I think my frequency lock works just fine.

I'm rebuilding my whole toolchain to see if it's an odd bug from originally having the older version of SDL installed.