A lot depends on the details. Are you looking to have the program contain it's own mini-web server, allowing you to run it on any box that runs the rest of your perl code, and interact with it via a web-browser? or are you looking to have an HTML interface that will send commands to your jukebox server that runs on the same machine as the webserver, allowing you to connect to that box from any machine with a browser? (I'd really recommend the latter over the former. Less overhead, less re-inventing the wheel.)

Assuming the latter, I'd just set up Apache with the default mod_cgi which lets you run perl scripts as CGI. (Mod_perl is wonderful, but takes a significant time investment to learn the tricks of.)

Perl scripts via CGI work on a sort of call-response system. The webserver gets the request, runs the perl script, and returns any output.

What you'd probably want is to have your jukebox server sitting on the box, accepting connections (on, say, port 8080). Your perl script, if called with no arguments, simply returns an HTML page of options. If a button is clicked/selected on this page, the perl script will connect to port 8080, send whatever authentication you require, and send "SET VOLUME to 80%" (or whatever). Once it gets a reply from your jukebox server, it prints the results in HTML, re-displays the original options (all in HTML), and finishes. The webserver returns this result to the browser.

If you designed your jukebox program was built as a sort of API, your jukebox program will be a gtk-perl program (or even console) that does a loop over $jukebox->accept_commands().. Likewise, the client, be it a looping gtk-perl program, or a one-shot CGI script, will call $jukebox_client->play(), $jukebox_client->set_volume() etc.

Of course, this is all IMHO, TIMTOWTDI, and I'm very new to socket programming myself, so I have only my recent successes to judge by.