mplayer

Redirecting audio to a remote host using esddsp

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

Playing audio on the NSLU2

3D Sound USB Audio Device

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 mplayer or 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.

  • MP3:
    • mplayer, mpg321, aplay, playsound, and splay don't work.
    • $ madplay foo.mp3: 17% CPU load
  • Ogg vorbis:
    • mplayer, aplay, playsound, and ogg123 don't work.
    • $ apt-get install libvorbisidec-dev
      $ cd /usr/share/doc/libvorbisidec-dev/examples
      $ make
      $ cat foo.ogg | ./ivorbisfile_example | aplay -f cd
      

      Result: 40% CPU load

  • MOD, XM, S3M, IT, etc.:
    • $ mikmod foo.mod: 10% CPU load (even with compressed MOD files)
  • WAV:
  • FLAC:
  • SPEEX:
    • $ speexdec foo.spx: doesn't work, 100% CPU load. Any known alternatives?
  • AU:
    • $ cat foo.au > /dev/dsp: 3% CPU load (but sounds crappy)
    • $ cat foo.au > /dev/audio: 3% CPU load (sounds better)
    • $ mplayer foo.au: 5% CPU load
    • $ aplay foo.au: 5% CPU load
    • $ playsound foo.au: 5% CPU load
  • AIFF:
    • $ sox foo.aiff -t wav - | aplay: 50% CPU load (a bit stupid, but it works)
  • Streaming MP3:
    • $ mplayer http://www.example.com/foo.mp3: doesn't work, 100% CPU load.
    • $ wget http://www.example.com/foo.mp3 -O - | madplay - : 17% CPU load
  • Streaming Ogg Vorbis:
    • $ cd /usr/share/doc/libvorbisidec-dev/examples
      $ wget http://www.example.com/foo.ogg -O - | ./ivorbisfile_example | aplay -f cd
      : 40% CPU load

The SlugAsAudioPlayer page in the NSLU2-Linux wiki might have further information on this topic.

Feel free to add comments if you know of other audio types which can be played on an NSLU2.

Mplayer remote and local vulnerability + security fix

The well-known video player Mplayer is vulnerable to a heap overflow when playing ASF files locally or from remote (streaming). The potential risks:

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!

Syndicate content