Author Topic: Quasi-Linux port of XMPlay  (Read 2556 times)


  • Posts: 5
Quasi-Linux port of XMPlay
« on: 25 Mar '08 - 05:56 »

Please forgive my rambling-on in advance; I can find it hard to get to the point at times. Scroll down the "The point" to get the "point" of the post, if you feel like being mean and not reading my storyline :p

The long, rambling storyline

I posted a little while ago that "Linux makes XMPlay cooler!". Well, a little while after that post, I decided to stop running the windowmanager I was using and switch to another windowmanager, one that doesn't support tray icons. Of course, this meant that XMPlay had to go... or not. I wouldn't be able to handle that. I use XMPLay for both MP3 and "special" playback as I have reverb and the equalization exactly where I want it, so... no. I can't switch, thankyou very much.

I thought about the whole XMPlay-on-Linux situation for a little while, and to be honest, for me, the experience hasn't been that good. I have an older P3 with a couple of ISA slots, and one of these has a SB16 that works to this day in it, and I play my music on this machine. I have a seperate desktop machine I use for general "navigation". So, for all intents and purposes, XMPlay isn't running on the same PC I would want to control it from.

Initially, I used XMPLay via a simple VNC link from my main machine to the "music box", but didn't really like that, so (this was before the windowmanager switch) I, in a fit of excitement, checked whether I could use X forwarding to get the window from the music box to my desktop. Well, it worked, and worked great... well, the main window did anyway (after it stopped flickering), and overall worked - provided I ignored the INFINITY+1 bugs and errors I kept encountering. The tray icon amazingly forwarded across the link as well, so that was really cool - for fluxbox at least, because fluxbox has tray icon support. (I've switched from flux since - Openbox is just a better windowmanager, IMO.)

So, after the WM switch, I initially "fell back" to the run-XMPlay-over-a-VNC-link I'd initially used, but since the music machine was being served by a 2ndary router I'll go so far to just understate as "iffy hardware" :P, I'll get 0% packet loss for however long then suddenly the router will drop 34976523485793823 packets (within which duration VNC simply won't respond), then suddenly go back to normal. So I got the wonderful idea that since VNC only transmits data when there's actually data to transfer, I opened a 2ndary VNC display in the first VNC display, put XMPlay in display #2, and open that in a window in display #1. Then, I can minimize display #2,no "movement" is transmitted over the bodgy router, then I can minimize the actual VNC window. So if you're following me and you're thinking "wait, when you want to do something as simple as change the volume you have to unminimize two windows?", you're right, and what's more, the router will suddenly go "ooh, packets!" *freeze* when I initially open VNC so I often have to wait 2-5 seconds before I'm able to pause my music for whatever (usually very urgent reason).

Here's a good bug for you: I have all my music on my file server - the music box just contains a hard disk with Linux, WINE and XMPlay on it, and not much else. I listen to my music via sshfs, which makes a remote filesystem appear like a local hard disk mount, except requested files are transferred over an ssh link in realtime. Well, XMPlay's "load the entire file into memory" scheme gives me two problems: since the link is so jittery (the same router that "powers" VNC also powers the link to the server), the transfer can sometimes go SCREEC--*continue* once or twice, giving me random jitters and jumps in my music. It doesn't happen often, but it does happen, which is not fun.

Here's the other bug - Ian, read this carefully, I've figured it out - I think I've said everything here except the starting line number of the segment of code you need to modify.

The file open function first takes the file, figures out how long it "probably" is, and then figures out how long it "really" is when the file is fully buffered. This method + sshfs = OUCH. It took me several weeks to understand why XMPlay thought my 2 hour live mixes (yes, I'm yet another person who listens to live mixes :P) were, um, 3:51 long. I recently saw my server's disk and my music box's Ethernet LED blinking at the same time (my music box is an IBM 300PL, the Ethernet LED is on the front of the case :D)... and put two and two together. Ian, you have a four (from the two and two I put together) that is laden with bugs: XMPlay thinks my music is 3:51 long because that's how much data it buffered via sshfs between the time it started buffering and the time it displayed the track length. Then, once the file has fully "buffered", XMPlay displays the correct track length. Maybe you should replace the track length for "weird" (aka sshfs/Linux-powered) streams with blinking ??:?? while the track is buffering, and when the track is fully buffered, replace it with the (known) file length. I'm having a wild guess here but I think the error is in file.c on line 129...

Oh, the entire library window doesn't work (no (would-be) visualizations for me :(), and tooltips screw up (I hate them - I want to turn those things off, they're SO ANNOYING, especially over a slow link).

"Wow man, that's hard. But why did you explain all that to me? I can't exactly buy you a new router..."

No, you don't have to. :P

The point

But I was wondering... has anyone considered writing a "Linux compatible" interface to XMPlay similar to mpd or the interface XMMS supports, so I can use a (ncurses- or commandline-based preferred :D) client to access my music, change the volume, manage playlists, etc? Such an option would be great, because (provided XMPlay was able to start up at all) I could use it via the Linux terminal, the way of the future :P :P

What you say now
"That's impossible, sorry."

« Last Edit: 25 Mar '08 - 06:28 by dav7 »