There are situations where you might want to redirect some audio you're playing on your local computer to another computer's speakers, potentially in a different room, or even anywhere on the Internet.
One of many possibilities to do that is to use the Enlightened Sound Daemon (EsoundD, or esd). It ships with a program called esddsp (apt-get install esound-clients) which can redirect various audio sources.
First, you have to start the esd daemon on a console on the remote host (the one which should output the audio on some speaker, for example 192.168.0.xxx) e.g. like this:
$ esd -public -nobeeps -tcp
You can do this as regular user (no need to be root) if you have the proper permissions. You also need to allow connections on port 16001 in your firewall settings. Then you can redirect audio to that daemon from another computer. In this example I'm redirecting some music using various players:
$ esddsp -s 192.168.0.xxx:16001 mpg321 -o esd foo.mp3 $ esddsp -s 192.168.0.xxx:16001 mplayer -ao esd foo.mp3 $ esddsp -s 192.168.0.xxx:16001 ogg123 -d esd foo.ogg
This also works fine for videos, in which case you can redirect the audio (but not video):
$ esddsp -s 192.168.0.xxx:16001 mplayer -ao esd foo.mp4
For the video player Miro, I've recently documented this in the Debian package's README.Debian file. Basically you have to edit ~/.xine/config and enable audio.driver:esd there, then start Miro with
$ esddsp -s 192.168.0.xxx:16001 miro
Audio will be emitted on the remote host, video remains on your local PC.
Some programs may also support esd natively, in which case esddsp is not required, e.g.
$ ogg123 -d esd -o host:192.168.0.14:16001 foo.ogg
I'm a happy NSLU2 user since a few months now, and I'm using it for all kinds of things, e.g. as a 24/7 remote ssh server at home (using DynDNS and the ddclient Debian package), as IRC logger (screen + irssi), etc. etc.
I was considering multiple options as to where/how to install the slug (USB thumb drive, Compact Flash, disk drive, ...) but I settled with a full Debian install on an 1 GB USB thumb drive for now. I implemented some measures to maximize the life time of the USB thumb drive, maybe I'll post some info on that later...
One new thing I've been trying lately is to use the slug as an audio player.
As it doesn't come with an integrated sound card, you have to use an external USB audio device. I've got mine (see photo) from eBay for ca. 5 Euro (+ shipping) and it works out of the box with Linux 2.6.18 using the
snd_usb_audio kernel module. You simply attach it via USB (the module is automatically loaded) and then attach external speakers to it. Here's an
lsusb of the device:
Bus 001 Device 011: ID 1130:f211 Tenx Technology, Inc.
One problem with playing audio on the slug is the slow CPU. At 266 MHz (and without FPU!) playing audio with "normal" audio players such as
mpg321 is not possible. But there are several ways to make the slug play your favorite music. Here's a list of players I tested and a status report of whether they work at all. If yes, I listed a rough percentage of CPU load resulting from playing the music.
$ madplay foo.mp3: 17% CPU load
$ mikmod foo.mod: 10% CPU load (even with compressed MOD files)
$ flac123 foo.flac: 17% CPU load
$ speexdec foo.spx: doesn't work, 100% CPU load. Any known alternatives?
Feel free to add comments if you know of other audio types which can be played on an NSLU2.
High (arbitrary remote code execution under the user ID running the player) when streaming an ASF file from a malicious server, medium (local code execution under the user ID running the player) if you play a malicious ASF file locally. At the time the buffer overflow was fixed there was no known exploit.
Users of the older MPlayer 1.0pre7try2 should apply this patch in order to fix the security issue. CVS users should update to the most recent revision.
I tried to do the latter, but I stumbled over several problems. First, I noticed and filed a bug (I think) in Debian's libavcodec-dev package which prevented a successful compile. After a few more problems I gave up and stayed with 1.0pre7try2 by applying the above-mentioned patch. I'll wait a few more days until the MPlayer developers fix the build issues in CVS...
There's no known exploit in the wild yet, but I bet it won't take too long until one appears. So better fix your Mplayer!