Linux jukebox program help

[Trimoor]

I have been programming a jukebox program for Linux, and for the most part it works.
The problem is speed.  It's running on a P166 with 80MB ram.  I know I shouldn't expect much from this system, but it takes 3 whole seconds to display a single 1024x768 background.  I've had windows on a P133 that could do better.

It's written in Perl, running on redhat 9 running xwindows.  I think the big slowdown is coming from xwindows, but I have no idea how to get around it.  The GUI is nothing but a single background image with text overlayed.  The background changes depending on what mode it's sorting by (title, genera, author), and this is where the delay comes in.

Anyone have any idea how to make this run faster/more efficient?
I have included the source.

[jstorch]

Your question dragged me out of years of lurking

I'm working on something similar; a linux frontend to mame done in Python.  I have code done to parse mame's xml file, validated it against the roms on the drives, and even filter mature roms using catver.ini.

Like you, I'm still struggling with the GUI.  My first attempt was using wxPython (a wrapper for the wxWidgets cross platform GUI) but it's too slow and plain for what I want to do.  I'm leaning toward a hardware accellerated option or at least more direct access to the video card like OpenGL or SDL.  I'm embarrassed that I've been held up trying to get the darn Nvidia drivers to install.

Maybe there are perl wrappers for SDL?

Good luck on you project.

Regards,
Jim Storch

[TalkingOctopus]

I think there are both perl and python wrappers for SDL.  The python one I know of is called pygame.  I'm not sure if they will run any faster.  It should display to the screen quicky, but you will probably not get very good frames per second.   1024x768 is too high of a resolution for SDL, especially for such an old computer.  If you want good performance in SDL, you will have to keep track of dirty rectangles and then only blit the changed parts of the screen.  Good Luck.

[Howard_Casto]

No disrespect intended... but the problem you guys are facing is because you choose the wrong os to code in.

It's why saint reccomends that you stick to a m$ os in his book.  Quite frankly none of us hobby byoac programmers code for linux for the most part.  Mostly for the reasons you guys have already stumbled upon, namely there is nobody to help you. 

Also, there isn't much point to it really....  if a pc can run a guied linux then it can run windows and it's infinately easier to make an app from scratch for windows than for linux.  And if you look hard enough you probably won't even have to make an app as several will already exist. 

This has absolutely nothing to do with my feelings towards linux as a worthy os.... it's just a matter of common sense over determining if a certain solution is viable. 

linux overall is a much more "difficult" os to use on a mame cab.  It is possible, but due to lack of software, lack of support and lack of hardware compatability... it'll fight you every step of the way. 

[Trimoor]

I know Linux might be more difficult for some things, but once it's running, it's a hell of a lot more stable than m$.  Even with simple dedicated tasks, windows is always crashing on me.

The next reason is freedom.  Linux is free, m$ is not.  Linux is open source, m$ is not.  My program is open source freeware, many are not.

As for lack of support, how exactly does m$ provide support?  If you're rich enough to pay a m$ tech to tell you to restart windows, go ahead.  There are plenty of support forums for Linux, possibly even more than for m$.
If you have the money, you can hire a guru.  With the source available, they literally know Linux inside and out.

Go ahead and help m$ with their monopoly.  Don't act surprised when they take over the country.

There is a big difference between writing for m$ and writing portable code.  If m$ didn't have so many exclusive libraries, we probably wouldn't have a problem with portability.

</rant>

[jstorch]

Howard,

There are some excellent reasons for hobbyists to invest in Linux over Windows.  Linux runs on platforms as small as a stick of gum to one of the top four supercomputers.  For folks that enjoy home-built gizmos, Linux is an excellent platform.  It's completely open and you get an amazing amount of control.  Did you know that, out of the box, Linux supports more hardware than any other operating system?  It's lineage (UNIX) has 35 years of being a developer's workbench.

You mention Windows as being easier, but if folks in our hobby wanted ease -- they'd buy an Xbox.  If you have no problem with someone meticulously routing a control panel why does it annoy you when we don't go Windows?   

Windows is certainly a capable platform but there are trade-offs, especially if you're not a fan of their "visual" IDE's which have you sticking dinklets of code here and there until your project begins to feel like some kind of wailing wall.  I can see how paid developers working under deadlines want rapid application development and are willing to put up with vendor lock-in, product activation, convenient "breaks" in backwards compatibility when they feel you should upgrade, poor (by design) compatiblity with other platforms, and decades of dodgy tactics.  I'm growing increasing annoyed with all of it and their recent push towards being a DRM platform makes Linux very appealing to me.   

I do this for enjoyment.  None of us have common sense or we'd take our mame budgets and roll them into a 401K.   I didn't look to see if someone already wrote what I want because .. hey I want to write it.  I find coding under Linux very pleasant.  Plus, you know that tiny chemical reward your brain releases when you learn stuff?  Never ending supply of it. 

Regards,
Jim Storch

[GadgetGeek]

I think the problem is that you are trying to run it under X.  No need to do that.  Look at (as an example) AdvanceCD.  It runs a version of MAME without ever loading X.  Just like old-school DOS, you can do graphics from console.  SVGALIB and/or Framebuffer support is probably what you are wanting.  Allegro is possibly a good place to start looking (or SDL as others have pointed out). 

[Trimoor]

I'd like to use the advanceCD method, but it's incompatible with any of my old video cards.  (I can't even get advanceCD to run.)

I will look into SVGALIB and Allegro, but sadly, it would be easier and more cost effective to buy a faster computer.
There used to be a time when hardware was more expensive than software......

(Heh heh, I love telling off ms people.)

[phulshof]

Just read through the code of ArcadeMENU and MAMEd (www.xs4all.nl/~phulshof). Both (can) use SDL, and you should be able to get some ideas for your coding from there. Since MAMEd is focused on use under Linux (with or without X), the code is quite small, so it should be easy to understand. If you need any help, just send me an email, and I'll see what I can do. Either that or send me ideas/feature requests for MAMEd to make it usable for your cabinet.

[elvis]

linux overall is a much more "difficult" os to use on a mame cab.  It is possible, but due to lack of software, lack of support and lack of hardware compatability... it'll fight you every step of the way. 

Three utterly incorrect and completely uneducated remarks.  Ignore all of them folks.

1) Lack of software?  10,000 free packages certainly isn't lacking in anything.  If anything, I'll admit the sheer overwhelming number of applications is a bigger stumblnig block for most people, rather than the lack of them.

2) Lack of support?  Some of the most detailed support available in free mailing lists, documentation and forums around the web, and direct from the developers.  When's the last time a Microsoft coder hung out in a community forum and help the little people?  forums.gentoo.org has been rated as one of the best online support groups ANYWHERE.  Check them out for yourself.  After all, it's free!  That's right, you don't have to pay for support.  There are thousands of friendly geeks out there willing to help anyone with a linux problem.  Don't take my word for it... check the forums out!

3) Lack of hardware compatability?  You have got to be joking!  Give me almost any off-the-shelf PC and I'll have linux up and running in minutes.  Grab yourself a copy of Knoppix LiveCD, and you can boot straight off the disc!  No install necessary!  Watch as the CD configures itself for your machine in seconds.  Sure, I can find the odd obscure video or sata card that won't be detected "out of the box", but I can do that in Windows too.  99% of folks today will be running a P4 or AthlonXP/64, probably with onboard AC'97 audio, onboard ethernet (or a realtek based card), and an ATi, Nvidia, or Intel Extreme video card.  All of which are supported under linux and XFree86/xorg.  Where's the compatability problems there?

Oh, and when's the last time Windows installed to a SATA drive out of the box?  Never!  Hell, you need to buy a floppy drive (costing more than a CDROM these days) just to install SATA drivers on a clean Windows install!!!  Talk about backwards.  Oh, did I mention Linux supports almost all SATA chipsets natively?  Kiss your floppy drive goodbye!

Howard: you suffer from a problem called FUD.  Fear, Uncertainty and Doubt.  It sounds very much to me like you've had troubles with Linux in the distant past, and are basing your modern-day opinions on decade old software.  What would you say to me if I told you WinXP was a load of tosh because of bugs in Win95?  Have a think about it.  Better yet, trial Linux for more than 10 minutes, and get back to me.

ANYWAYS.... back on topic....

There are other options apart from X.  X is very big, and needs some grunt behind it (just like XP's gui does - don't tell me you'd EVER run XP on a P166).  If you don't want a whole X install, there's always fbdev and svgalib.  Both of which work remarkably well on lower-end systems.

Likewise, analyse your RedHat setup.  The kind folks at RedHat ensure that every service under the sun is loaded and running when you install it with the default options.  Try turning off things you don't need (do you really need sendmail and squid running on a standalone box???).  Alternatively, head for a nice, lean, customisable distro like Debian.  You'll be amazed at how zippy it can be.

[Chris]

Does nobody think that the fact that he's trying to do this in Perl has anything to do with this?

[GadgetGeek]

Does nobody think that the fact that he's trying to do this in Perl has anything to do with this?

Maybe some, but given the hardware he said he's using, I'd be more inclined to blame it on X.  My Celeron 366 w/ 256 megs is pretty sluggish running KDE on X. 
Maybe it is the combination of Perl and X and it is causing some massive swapping? 
Speaking of Perl, CmdrTaco's (of Slashdot fame) Mame FE was written in Perl and is downloadable from his site.  It might offer some help and/or insights as well.

[Chris]

(Heh heh, I love telling off ms people.)

Actually, I think you told off yourself.  Your own original post says "windows on a p133 could do better"...

[elvis]

Does nobody think that the fact that he's trying to do this in Perl has anything to do with this?

Maybe some, but given the hardware he said he's using, I'd be more inclined to blame it on X.

I'd have to agree with X being the primary issue.  Sure, Perl isn't the lightest language out there resource-wise, but X is a heavyweight in its own right.  The combination of them can't be super.  As mentioned, perhaps throwing some SDL in there will speed up the screen-drawing parts.

I think it's honorable that folks are coding on sub-200MHz machines to ensure their stuff works on anything, but honestly for a jukebox I'd be looking at double those speeds as my entry-level machine.  I guess it depends if this is intended for proper embedded-design markets, or just home tinkering.  If it's the latter, than there's no harm in requiring some beefier components.  After all, I think I've given away all of my sub-200MHz machines to friends and family as linux firewall/router boxes by now!

[SirPoonga]

No disrespect intended... but the problem you guys are facing is because you choose the wrong os to code in.

Actually, linux ans sdl are perfect for this type of thing.

However, his problem is the P166...  The min requirements to play an mp3 are P100 to give an idea of scale.

[Trimoor]

Well, just about all of the music are oggs, so it needs less processing power.
mp3 is evil.

[Chris]

No disrespect intended... but the problem you guys are facing is because you choose the wrong os to code in.

Actually, linux ans sdl are perfect for this type of thing.

On the stated platform, I think DOS would be the more appropriate answer.  DOSCab Jukebox will run fine on that system.

--Chris

[SirPoonga]

No disrespect intended... but the problem you guys are facing is because you choose the wrong os to code in.

Actually, linux ans sdl are perfect for this type of thing.

On the stated platform, I think DOS would be the more appropriate answer.

[Chris]

No disrespect intended... but the problem you guys are facing is because you choose the wrong os to code in.

Actually, linux ans sdl are perfect for this type of thing.

On the stated platform, I think DOS would be the more appropriate answer.

[Trimoor]

Yeah, but it doesn't read the ext3 file system which all my music is on.
Does it read MIDI?
SNES SPC? NES NFS?  (mine doesn't read game formats yet, but it will.)

I've put too much time in the program to abandon it now.

[Chris]

Yeah, but it doesn't read the ext3 file system which all my music is on.
Does it read MIDI?
SNES SPC? NES NFS?

[Trimoor]

I tried reducing it to 800x600, but it still pretty slow.
I'm still looking into SDL.

[Chris]

You may also want to try Allegro.  Allegro will work with either X or SVGALIB, and as a side benefit your code will also compiile on DOS, Windows, and the Mac.  There are excellent MP3 and OGG libraries available for Allegro as well.  Take a peek at http://alleg.sourceforge.net.

--Chris

[TalkingOctopus]

You may also want to try Allegro.

[Chris]

SDL runs on almost any platform!

[TalkingOctopus]

SDL runs on almost any platform!

[Dermbrian]

Yeah, but it doesn't read the ext3 file system which all my music is on.
Does it read MIDI?
SNES SPC? NES NFS?  (mine doesn't read game formats yet, but it will.)

I've put too much time in the program to abandon it now.

MIDI would be easy enough; I could add it in a few minutes.  The others wouldn't.

Is lowering the resolution or color depth an option?  That might speed things up...

--Chris

Chris,

Add MIDI support to WinCAB?  That sounds like a great idea, if it really is extremely simple.  I have acouple of MIDI files that I actually listen to, and the jukebox could work for karaoke that way, too.

Maybe in Beta 7?  I think a lot of people are looking forward to Beta 6.

Brian

[Chris]

Yeah, but it doesn't read the ext3 file system which all my music is on.
Does it read MIDI?
SNES SPC? NES NFS?

[Trimoor]

I switched to SDL and started writing it in C, and it now runs full speed.  Now I just need to finish translating the rest of the Perl.....
Is there any interest here for another jukebox program?  I'm sure it could be ported to windows without too much trouble.  (why you'd want to I don't know.....)