The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

PHP WinAMP Control Module

Folks-

I've created a freeware native Win32 module for controlling v1.x and v2.x of Nullsoft's WinAMP Multimedia Player using the PHP programming language. It is currently beta-level software and I'm looking for willing beta testers to play with it and provide feedback. The module was compiled for PHP v4.1.1 but it may work with other 4.1.x PHP versions as well.

If anyone has questions, comments or suggestions related to this module you can contact me at the email address included with the above documentation, or, of course, post a message here :-) Thanks for the feedback, and have fun!

I have a WinNT computer with a great sound card and speakers sitting in the corner on a hardware keyboard/mouse/monitor switch with three other machines. This module lets me play my mp3's on that computer and control it remotely from any other computer (or palm pilot or pager or cell phone) in the house.

There are also WinAMP plugins that let you stream mp3's over the Internet. This module could be used to create a Web-accessible interface for that service.

Originally posted by Marshall I have a WinNT computer with a great sound card and speakers sitting in the corner on a hardware keyboard/mouse/monitor switch with three other machines. This module lets me play my mp3's on that computer and control it remotely from any other computer (or palm pilot or pager or cell phone) in the house.

There are also WinAMP plugins that let you stream mp3's over the Internet. This module could be used to create a Web-accessible interface for that service.

And, last but not least... it was fun to write :-)

- Marshall

hahaaa! Very cool idea. VERY cool. In fact, so cool, I think I'm gonna build myself one of those. I'm getting a Compaq iPaq H3870 with bluetooth soon, and combined with my Ericsson r520m, I have a constant, wireless connection to the Internet pretty much everywhere. I could turn on Barry Manilow (no pun intentended) on the way home with the girls!

Re-inventing the wheel

I also find your ideas very, very cool, and that's why I implemented them, about 1.5 years ago...

Note: I only implemented the PHP side: a simple class to control Winamp. On the Winamp-side, there already exists a nice HTTP plug-in which you can call from the client. This plug-in is called httpQ and is available for free download on http://www.csc.uvic.ca/~karvanit/winamp/
It's free for personal use. I did write a small C++ application for XMMS (Linux) that does the same as httpQ, but as currently only my local server has Linux, I'm not using that.

Anyway, what I built is a little different from what you did: first I designed a PostgreSQL database that was able to store albums. This is - naturally - a 3NF normalized design, so every artist's name is stored only once, instead of with every track it's coupled with (like in those ugly MP3-tags)... The second step in my scheme involved buying a large harddisk, and storing all my albums on it. It now holds about 350 hours of music, all in high quality MP3 (about 30 GB). Finally, I built a website on top of that, and every user on the intranet can log in with his/hers own username and password.

As for Winamp: users always have a small link in the top right corner of the browser window to the artist(s), album, and track they're currently listening to. Music can immediately be played or enqueued in Winamp (or XMMS for Linux) by simply clicking on a small icon on the website. Also, users can create their own playlists and store them in the database, and send these lists to Winamp with one click. Finally, the system keeps a list of favorite albums, artists and tracks for every user, so everyone has his/hers own personal home page on the site.

At the moment I'm thinking about releasing my complete site to the public for free, but there are some problems, mainly in the maintenance department: I now upload new albums by hand (an ugly Perl-script, actually) and haven't yet written a nice administration program for it. As I think an application should only be released to the public when it's completely finished, this is holding me back from putting it on the web. A second task that needs to be done is implement a rating system. The database already has support for it, but the site hasn't. Finally, the database supports 'genre' and 'mood' for tracks and albums, but these aren't implemented yet on the site either. The reason is that I'm actually quite happy with what I have thus far, and are busy with all kinds of other things.

I'm currently developing a framework for generating database administration sites, and once that's finished it shouldn't be too hard to create an administriation site for my music database. So maybe, in a month or so, I will put my stuff on the net for all to enjoy. I've been using it at home now for 1.5 years, and everybody here loves it.

voostind writes:
I also find your ideas very, very cool, and that's why I implemented them, about 1.5 years ago...

Glad you like them :-)

From what you've described your front-end design may be abstract enough to function with either httpQ or php_winamp (I'll definitely take a look at your system when you make it available). You may even find that it works faster with php_winamp then with your current httpQ interface.

voostind writes:
Note: I only implemented the PHP side: a simple class to control Winamp. On the Winamp-side, there already exists a nice HTTP plug-in which you can call from the client.

The php_winamp module is simply another approach to the PHP <> WinAMP integration problem. This module provides a direct light-weight interface to the WinAMP executable via the native Win32 messaging system. Using the httpQ plug-in involves the additional overhead of initializing socket connections and negotiating the HTTP protocol -- an extra step in the communication process.

You've got the right idea, though. Take what's available when planning your project and do whatever you like with it :-)

One little problem?

The php_winamp module is simply another approach to the PHP <> WinAMP integration problem. This module provides a direct light-weight interface to the WinAMP executable via the native Win32 messaging system. Using the httpQ plug-in involves the additional overhead of initializing socket connections and negotiating the HTTP protocol -- an extra step in the communication process.

Yes, but doesn't your module suffer from one big problem? Your webserver has to be on the same machine as Winamp. And in my case, that's inacceptable. For one thing, I think a good webserver should run on Linux, and a good desktop machine should run on Windows. (Note: This is just my personal opinion, there's absolutely no flame intended!) Another thing is that, using httpQ, you can have as many independent listeners as you like, instead of the one Winamp on the server. But that's just my two cents...

True, you will need to have a Web server running on the machine with WinAMP. But then, in your case, httpQ is functioning as the Web server -- and if you're going to use a Web server you might as well use one that's been thoroughly stress-tested (like Apache or IIS).

Another thing is that, using httpQ, you can have as many independent listeners as you like, instead of the one Winamp on the server.

Shoutcast, the service & plug-in that supports multicasts of music from WinAMP, is independant of httpQ. httpQ is just one possible interface for controlling it.

True, you will need to have a Web server running on the machine with WinAMP. But then, in your case, httpQ is functioning as the Web server -- and if you're going to use a Web server you might as well use one that's been thoroughly stress-tested (like Apache or IIS).

Correct, but there's a remark to be made here: Every client runs his own - very small - 'webserver', httpQ. Client computers don't want a big web server like Apache or IIS just to listen to music.

Shoutcast, the service & plug-in that supports multicasts of music from WinAMP, is independant of httpQ. httpQ is just one possible interface for controlling it.

Maybe I didn't make my self very clear, but I don't use streams like Shoutcast or Icecast. In my case, it looks a bit like this:

- There's a 'big' Apache web server with a 'big' PostgreSQL database
- There's a fileserver (Linux Samba) with all the music (MP3)
- Users select the music they want to hear on the site, and INSTANTLY hear it, because the web server (PHP) sends the name of the files to play to the tiny httpQ plug-in on the client machine. So, on the client, it looks like it's reading 'local' files.

The only drawback is that this only works on intranets (you need LAN access to the music). But this is not really a drawback, as sending your own high-quality music (say 256 kbps MP3) over the internet is most likely illegal. Also, streaming has two problems:
- It isn't INSTANTENUOUS. If you enqueue a complete playlist in a stream, you don't see a list of files in Winamp, but just a single file (the stream). When I enqueue a complete album, I want to be able to skip tracks, or listen to another track twice. Or shuffle them. Or whatever.
- It's streaming ALL THE TIME, even if there aren't listeners. This is not a big issue, but it's there.

By the way, I did experiment with streaming (Icecast) and am thinking about something to put in my site, but having the option to instantly select files and play them still has my personal preference.

Anyway, whatever makes your boat float, you should use. There's more ways to achieve the same goal. :-)

- There's a 'big' Apache web server with a 'big' PostgreSQL database
- There's a fileserver (Linux Samba) with all the music (MP3)
- Users select the music they want to hear on the site, and INSTANTLY hear it, because the web server (PHP) sends the name of the files to play to the tiny httpQ plug-in on the client machine. So, on the client, it looks like it's reading 'local' files.

Hmm... yes, I can see the advantages to this type of distributed instantaneous playback system. I wonder, though, if we can come up with a design independent of WinAMP-specific functionality. It would be very cool if the system could support any mp3 media player installed on the client's computer.

The problem with most Web browsers is that they download files to a temporary directory and then send the local path to the program associated with the file's extension. This operation is what causes the delay in playback. Maybe a browser plugin or signed applet could be used to circumvent this limitation by loading the associated application directly with the remote file path instead?

httpQ-less

Whenever you want all your clients to be able to play files seperate from each other, you will need some kind of server-program on the client that communicates with the website. If you want to implement this yourself, you can define a protocol that does exactly what you want, and it'll probably work with UDP.

httpQ solves the problem with a small HTTP-server. This approach is arguable, but it does work very well. The only real problem is that it only works as a Winamp plug-in. (This of course does have the advantage that clients can install it and forget about it; it'll run automatically with Winamp.)

I 'reverse engineered' the httpQ-protocol in about 1 hour, and wrote a Perl script that works as the httpQ-server. This script runs on Linux and communicates with XMMS. In other words: making httpQ work with other programs isn't that hard. If you want my Perl script or the XMMS-remote controller (a C++ program) just let me know, and I'll post them here. The same goes for the PHP class that communicates with httpQ (or the Perl script).

Vincent

BTW: if you do this on an intranet, and use file sharing for your music files, your browser doesn't need to copy files to the client.

Whenever you want all your clients to be able to play files seperate from each other, you will need some kind of server-program on the client that communicates with the website.

Not really. Since you're using Sampa to share the files as a network FS you could get instantaneous playback simply by opening up Windows Explorer, browsing to the network drive, and double clicking the media file. The trick is passing the network address to the media player and letting it stream the file over the network instead of using the default browser functionality, which involves downloading a local copy of the file. httpQ is only one way to accomplish the former -- it listens on a network port, you send it the network path of the file, and it starts playing that file. An alternative would be to initialize the default media player using the network path as a command-line argument, the same as what happens when you double-click the file name in Windows Explorer. The second method would allow us to do without any server software (except, of course, the network FS implementation) on the client machines, and could probably be accomplished via a signed Java applet or JavaScript code (which would make it cross-browser as well as cross-media player).

Clicking this link would call the Java applet, which reads the Windows Registry entry associated with the .mp3 file extension, replaces %s (in the Registry value) with the specified network path, and executes the command-line. The command-line loads the default media player and causes it to begin playing the specified song.

PHP WinAMP Control Module v1.1

The interface is the same as v1.0 but the functions now do validity testing on parameters. If you pass an invalid parameter value -- for instance, a value of 5 when the function is expecting a boolean -- it will throw a Warning message.