I built a four-output MP3 player in 1999 and found it to be a pretty reasonable task if you understand the basics of the software side of the game. For reasons that I won't debate, I was using Windows at the time (don't beat on me, I'm a Macintosh/Windows/FreeBSD user and programmer, so don't go all/.-religious war on me).
We used a PII 400 and got a very reliable 5 output stream box using a multi-output card that isn't manufactured any longer. I tried a number of these cards and most of them worked well. [ As an aside, the MOTU high-end units are excellent if you are going to put the output into high-quality amps and speakers, but they are expensive.]
From the software side, we used a custom, multi-threaded MP3 player compiled using Intel's optimizing compilers (which mad a huge difference on the PII) and used a graphical front end with a screen-per-room display showing the album art (scanned in by the user or installer) along with the tracks, play lists, etc.
We did run into a control problem, even though most of our customers were using systems with centrally located gear, which was that getting a PC to run with multiple distinct (and user-uninterruptable) displays simultaneously was expensive and difficult. To supplement this, we created a serial-based interface which allowed for play lists, random play, and basic start/stop/skip controls for each room and could be combined with the GUI over a commercial home control system (like Crestron or AMX).
Basically, we would watch the serial port for commands and respond to the control system by flipping individual windows that corresponded to the room that was controlling the system at the time. The control system, in turn, would put show the screen output in a kind of touch screen mode and send mouse locations over the serial port back to our controller. This worked, but was expensive and complex to handle, since only one room could have control over the GUI at the time. For things like displaying the playing tracks and album along with the next track and providing basic control of the start/stop/skip/repeat sequences, we could send text to the control system over the serial port and it would be displayed on the screen in text fields (allowing the main display to be required only for play-list management). This helped quite a bit.
The control piece was far and away the most difficult part of the project, but since you only have to satisfy yourself, and not the marketplace, I'd suggest that you might find an 802.11-capable PDA as a controller might be useful (and fun to work on). Of course, then you have to either develop your own control protocol or use some kind of CGI and a web server to do the control, but if you separate the players into individual threads or processes that can be easily located, you should be able to send messages (UNIX signals, perhaps) to them and get the level of control that you need.
From a technical perspective, any OS that has preemptive threading and good interprocess communication should be fine for building this kind of system. We found that by creating our own player (despite the need to license the decode patent from Fraunhofer if we were to sell it commercially), we were able to get a finer control of the playback features (such as pause/skip/repeat) than by using single-shot mp3 play commands that were available at the time. I'd suggest looking for how you can get those useful features if you decide to use existing commands in a Linux environment.
Of course, on a Macintosh, you can do the playback through QuickTime, which is going to be easy and highly-controllable, so you have that oppotunity too.
In the end, we found that the customers who got it loved it, but that the installers we were trying to sell to weren't interested in buying a product that required some set-up.
Slashdot Mirror
We used a PII 400 and got a very reliable 5 output stream box using a multi-output card that isn't manufactured any longer. I tried a number of these cards and most of them worked well. [ As an aside, the MOTU high-end units are excellent if you are going to put the output into high-quality amps and speakers, but they are expensive.]
From the software side, we used a custom, multi-threaded MP3 player compiled using Intel's optimizing compilers (which mad a huge difference on the PII) and used a graphical front end with a screen-per-room display showing the album art (scanned in by the user or installer) along with the tracks, play lists, etc.
We did run into a control problem, even though most of our customers were using systems with centrally located gear, which was that getting a PC to run with multiple distinct (and user-uninterruptable) displays simultaneously was expensive and difficult. To supplement this, we created a serial-based interface which allowed for play lists, random play, and basic start/stop/skip controls for each room and could be combined with the GUI over a commercial home control system (like Crestron or AMX).
Basically, we would watch the serial port for commands and respond to the control system by flipping individual windows that corresponded to the room that was controlling the system at the time. The control system, in turn, would put show the screen output in a kind of touch screen mode and send mouse locations over the serial port back to our controller. This worked, but was expensive and complex to handle, since only one room could have control over the GUI at the time. For things like displaying the playing tracks and album along with the next track and providing basic control of the start/stop/skip/repeat sequences, we could send text to the control system over the serial port and it would be displayed on the screen in text fields (allowing the main display to be required only for play-list management). This helped quite a bit.
The control piece was far and away the most difficult part of the project, but since you only have to satisfy yourself, and not the marketplace, I'd suggest that you might find an 802.11-capable PDA as a controller might be useful (and fun to work on). Of course, then you have to either develop your own control protocol or use some kind of CGI and a web server to do the control, but if you separate the players into individual threads or processes that can be easily located, you should be able to send messages (UNIX signals, perhaps) to them and get the level of control that you need.
From a technical perspective, any OS that has preemptive threading and good interprocess communication should be fine for building this kind of system. We found that by creating our own player (despite the need to license the decode patent from Fraunhofer if we were to sell it commercially), we were able to get a finer control of the playback features (such as pause/skip/repeat) than by using single-shot mp3 play commands that were available at the time. I'd suggest looking for how you can get those useful features if you decide to use existing commands in a Linux environment.
Of course, on a Macintosh, you can do the playback through QuickTime, which is going to be easy and highly-controllable, so you have that oppotunity too.
In the end, we found that the customers who got it loved it, but that the installers we were trying to sell to weren't interested in buying a product that required some set-up.
O