psi42
03-30-2004, 07:56 PM
Yay.
If you're like me, you probably have a few old (old as in 100mhz+, not old as in VIC 20) computers lying around, maybe even strewn together in a lan.
Let's say you're working on an old machine boasting a screaming fast 350Mhz AMD K6-2. While surfing the internet using your lightweight web browser, which complements your collection of lightweight applications and utilities, you decide you need some music. And so you fire up your favorite lightweight audio player (for virtue of this tutorial, we're just going to use "play") to play some sound.
play foo.ogg
Of course, you've compressed your song using the Free, Open Ogg Vorbis audio codec, graciously brought to us by Xiph.org.
But hold on. Suddenly your menus are a bit sluggish. Your lightweight xterm takes a little longer to start up. What's going on?
Let's take a look at what top has to say.
CPU states: 83.5% user 5.1% system 0.0% nice 0.0% iowait 11.2% idle
Mem: 61720k av, 59304k used, 2416k free, 0k shrd, 900k buff
22852k active, 28864k inactive
Swap: 188960k av, 57180k used, 131780k free 11308k cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
14122 maedhros 18 0 1376 1372 696 R 78.6 2.2 1:04 0 sox
13789 root 9 0 49756 20M 8820 R 8.2 34.1 7:58 0 X
14098 maedhros 13 0 1072 1032 816 R 0.7 1.6 0:01 0 top
14096 maedhros 9 0 1252 1160 1000 S 0.5 1.8 0:00 0 aterm
14038 maedhros 9 0 5588 4492 3672 S 0.1 7.2 0:04 0 gaim
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
14122 maedhros 18 0 1376 1372 696 R 78.6 2.2 1:04 0 sox
Ugh! Look at that CPU usage. Wow! I usually see an average of about 30% cpu used for decoding ogg files. I know playing with ogg123 only shows about 14%. I'd like to know how to get an accurate measurement of the system load of ogg decoding (anyone?). I am not sure exactly the cause for the discrepancies, but either way the drag on the system is noticable nonetheless.
It is in this point that you hear the wind knock the door open. You look over (you actually have to do this to make the magic work) and you see your doorstop, another old computer. And you think, well, why can't that thing shoulder the vorbis decoding and just send the decoded audio over to my computer? It's linux, isn't it? I can make it do whatever I want.
It was only after pulling my hair out trying to get this little set up to work that I finally realized I had the thing set up completely wrong. Much like X11, the definitions of client and server are different from what one would at first assume. The esd server runs on the computer you want to receive the decoded audio. The esd client sends the decoded audio to the server. The server serves this stuff to your sound device. It was only after I found some decent documentation (http://www.shankerbalan.com/tech/esound.txt) that I was able to get this figured out. I think no one should have to go through all the trouble I did to get this thing to work, so I figure I might as well share the knowledge. To this end, I have posted a little howto-thing right here. :)
Let's get started.
First of all, let's get one thing settled.
The esd SERVER is a piece of software that runs on the computer you wish to be receiving decoded audio. It takes care of sending that audio to the sound device. The server can also do other things, like play multiple sounds at once, but one should do one thing at a time, no?
The esd CLIENT is a piece of software that does it's thing and sends audio to the esd SERVER. In our case, this program will be running on a different computer than the esd server.
My stupid assumptions:
I assume you have two computers, both with working installs of linux. Both computers in this example are running Slackware (specifically, the one running the server is running Slack 9.1, the other has Slack 9.0), but you should be able to adapt this to any distro.
I assume your two computers are hooked together on a working lan. If you don't know how to set up a working lan, there is an excellent tutorial here (http://justlinux.com/forum/showthread.php?s=&threadid=124648).
I assume the device you are going to be running the esd server on has a working soundcard and working speakers.
I assume you have esd installed, and have client programs capable of using esd. I know xmms has an esd output plugin built in.
I assume you will figure out how to get your security hardware/software to allow the necessary connections.
What we must needs accomplish:
Okay. Our goal here is to sit at one computer, running esd, and use xmms in a way that seems exactly the same as before, except that the ogg decoding is done elsewhere.
So...here is what must be done.
On the machine we are currently on, we need:
1) A running esd server expecting connections
2) A way to control the xmms client without physically going to a different computer
On the machine doing the dirty work, we need:
1) Xmms set up to output decoded audio to our esd server.
Let's take care of the server first.
Server setup:
On our server machine, we need to set up our esd server. This is as simple as: esd -nobeeps -tcp -public
The nobeeps option will supress esd's startup sound effects. You should remember this, because those beeps are really loud and scary. The public option will allow other machines to access your esd. The tcp option, well, means it will use tcp.
That's it. We're done here. Make sure esd doesn't die.
Client setup:
In order to let our client programs know where the esd server is, you need to set the ESPEAKER environment variable. This should be:
<server ip address>:<port>
where the server ip address is, you guessed it, the ip address of the server machine. The port is by default 16001, and unless you told the esd server to listen on a different port, it will be 16001. So... export ESPEAKER=0.0.0.0:16001Of course, replace 0.0.0.0 with the real ip address of your server.
Now, start up xmms. Right-click-->Options-->Preferences-->Audio I/O plugins. Select eSound output as your output plugin. Click Configure. You should see it already set up with the correct IP address and port, since it automatically reads the $ESPEAKER variable. Nice job. You shouldn't need to change anything here.
Testing it:
Head back to your server and make sure esd is still running. Now go over to your client and hit play on xmms. Make sure your speakers are plugged in. :) You should hear beautiful melodies coming out of your server's speakers. Magic! You will feel your server machine is a bit nippier now that it has one less thing to do.
Final touches:
You probably don't want to enter all of these commands every time you want to play a song. You probably don't want to have to walk over to another computer to control xmms. You might even want to run that machine headless, and have it do other tasks as well.
You can achieve a quick fix for these problems by creating some simple shell scripts and controlling xmms remotely through ssh.
On your client machine, make sure sshd is running. sshd is the Open Secure Shell daemon which allows you to connect from another computer and log in as if you were physically seated on the machine. Be sure you have taken into account any security issues before enabling this.
Open up /etc/ssh/sshd_config in your favorite text editor. Find the entry marked X11Forwarding. Set it to yes. Save, exit, and restart sshd.
This adds another level of complexity, as you are running an ssh server on the machine running the esd client. Confusing, no?
On your server machine (keeping track of which is which, right?) try and log in to the client. Run
ssh -X -lusername 0.0.0.0Replace 0.0.0.0 with the real IP address of the client, and username with your username. The -X option tells ssh to forward X11 events.
You should now have a login shell.
Let's set up those shell scripts. On your client machine, create a file somewhere in your $PATH and open it up in your favorite text editor. All you need here is: #!/bin/bash
export ESPEAKER=0.0.0.0:16001
exec xmms
exit
Now chmod +x it to make it executable.
On the server, the script you will want is:#!/bin/bash
esd -nobeeps -tcp -public &
exec rxvt -e ssh -X 0.0.0.0 exmms
exit
Again, replace 0.0.0.0 with your ip address and rxvt with your favorite x terminal emulator. Replace exmms with the name of the script you created on the client. chmod +x it.
Testing it:
Now, kill all instances of esd and xmms on all machines.
Run the script you made on the server machine. A terminal will pop up asking for your password. Type it in. (Once I RTFM and figure out how to make ssh connect without a password, I will add that procedure here as well.)
Xmms should pop up. Go ahead and play a song.
Let's check top:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
14288 maedhros 13 0 552 552 456 S 1.9 0.8 0:05 0 esd
14290 maedhros 10 0 1740 1736 1268 S 0.5 2.8 0:13 0 ssh
Ah... much better. :) Enjoy the fruits of your labor.
Comments and corrections are welcome. If you've read this far, it means you have a lot of determination. :)
...Refer all complaints to /dev/null
avoir fun :)
~psi42
If you're like me, you probably have a few old (old as in 100mhz+, not old as in VIC 20) computers lying around, maybe even strewn together in a lan.
Let's say you're working on an old machine boasting a screaming fast 350Mhz AMD K6-2. While surfing the internet using your lightweight web browser, which complements your collection of lightweight applications and utilities, you decide you need some music. And so you fire up your favorite lightweight audio player (for virtue of this tutorial, we're just going to use "play") to play some sound.
play foo.ogg
Of course, you've compressed your song using the Free, Open Ogg Vorbis audio codec, graciously brought to us by Xiph.org.
But hold on. Suddenly your menus are a bit sluggish. Your lightweight xterm takes a little longer to start up. What's going on?
Let's take a look at what top has to say.
CPU states: 83.5% user 5.1% system 0.0% nice 0.0% iowait 11.2% idle
Mem: 61720k av, 59304k used, 2416k free, 0k shrd, 900k buff
22852k active, 28864k inactive
Swap: 188960k av, 57180k used, 131780k free 11308k cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
14122 maedhros 18 0 1376 1372 696 R 78.6 2.2 1:04 0 sox
13789 root 9 0 49756 20M 8820 R 8.2 34.1 7:58 0 X
14098 maedhros 13 0 1072 1032 816 R 0.7 1.6 0:01 0 top
14096 maedhros 9 0 1252 1160 1000 S 0.5 1.8 0:00 0 aterm
14038 maedhros 9 0 5588 4492 3672 S 0.1 7.2 0:04 0 gaim
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
14122 maedhros 18 0 1376 1372 696 R 78.6 2.2 1:04 0 sox
Ugh! Look at that CPU usage. Wow! I usually see an average of about 30% cpu used for decoding ogg files. I know playing with ogg123 only shows about 14%. I'd like to know how to get an accurate measurement of the system load of ogg decoding (anyone?). I am not sure exactly the cause for the discrepancies, but either way the drag on the system is noticable nonetheless.
It is in this point that you hear the wind knock the door open. You look over (you actually have to do this to make the magic work) and you see your doorstop, another old computer. And you think, well, why can't that thing shoulder the vorbis decoding and just send the decoded audio over to my computer? It's linux, isn't it? I can make it do whatever I want.
It was only after pulling my hair out trying to get this little set up to work that I finally realized I had the thing set up completely wrong. Much like X11, the definitions of client and server are different from what one would at first assume. The esd server runs on the computer you want to receive the decoded audio. The esd client sends the decoded audio to the server. The server serves this stuff to your sound device. It was only after I found some decent documentation (http://www.shankerbalan.com/tech/esound.txt) that I was able to get this figured out. I think no one should have to go through all the trouble I did to get this thing to work, so I figure I might as well share the knowledge. To this end, I have posted a little howto-thing right here. :)
Let's get started.
First of all, let's get one thing settled.
The esd SERVER is a piece of software that runs on the computer you wish to be receiving decoded audio. It takes care of sending that audio to the sound device. The server can also do other things, like play multiple sounds at once, but one should do one thing at a time, no?
The esd CLIENT is a piece of software that does it's thing and sends audio to the esd SERVER. In our case, this program will be running on a different computer than the esd server.
My stupid assumptions:
I assume you have two computers, both with working installs of linux. Both computers in this example are running Slackware (specifically, the one running the server is running Slack 9.1, the other has Slack 9.0), but you should be able to adapt this to any distro.
I assume your two computers are hooked together on a working lan. If you don't know how to set up a working lan, there is an excellent tutorial here (http://justlinux.com/forum/showthread.php?s=&threadid=124648).
I assume the device you are going to be running the esd server on has a working soundcard and working speakers.
I assume you have esd installed, and have client programs capable of using esd. I know xmms has an esd output plugin built in.
I assume you will figure out how to get your security hardware/software to allow the necessary connections.
What we must needs accomplish:
Okay. Our goal here is to sit at one computer, running esd, and use xmms in a way that seems exactly the same as before, except that the ogg decoding is done elsewhere.
So...here is what must be done.
On the machine we are currently on, we need:
1) A running esd server expecting connections
2) A way to control the xmms client without physically going to a different computer
On the machine doing the dirty work, we need:
1) Xmms set up to output decoded audio to our esd server.
Let's take care of the server first.
Server setup:
On our server machine, we need to set up our esd server. This is as simple as: esd -nobeeps -tcp -public
The nobeeps option will supress esd's startup sound effects. You should remember this, because those beeps are really loud and scary. The public option will allow other machines to access your esd. The tcp option, well, means it will use tcp.
That's it. We're done here. Make sure esd doesn't die.
Client setup:
In order to let our client programs know where the esd server is, you need to set the ESPEAKER environment variable. This should be:
<server ip address>:<port>
where the server ip address is, you guessed it, the ip address of the server machine. The port is by default 16001, and unless you told the esd server to listen on a different port, it will be 16001. So... export ESPEAKER=0.0.0.0:16001Of course, replace 0.0.0.0 with the real ip address of your server.
Now, start up xmms. Right-click-->Options-->Preferences-->Audio I/O plugins. Select eSound output as your output plugin. Click Configure. You should see it already set up with the correct IP address and port, since it automatically reads the $ESPEAKER variable. Nice job. You shouldn't need to change anything here.
Testing it:
Head back to your server and make sure esd is still running. Now go over to your client and hit play on xmms. Make sure your speakers are plugged in. :) You should hear beautiful melodies coming out of your server's speakers. Magic! You will feel your server machine is a bit nippier now that it has one less thing to do.
Final touches:
You probably don't want to enter all of these commands every time you want to play a song. You probably don't want to have to walk over to another computer to control xmms. You might even want to run that machine headless, and have it do other tasks as well.
You can achieve a quick fix for these problems by creating some simple shell scripts and controlling xmms remotely through ssh.
On your client machine, make sure sshd is running. sshd is the Open Secure Shell daemon which allows you to connect from another computer and log in as if you were physically seated on the machine. Be sure you have taken into account any security issues before enabling this.
Open up /etc/ssh/sshd_config in your favorite text editor. Find the entry marked X11Forwarding. Set it to yes. Save, exit, and restart sshd.
This adds another level of complexity, as you are running an ssh server on the machine running the esd client. Confusing, no?
On your server machine (keeping track of which is which, right?) try and log in to the client. Run
ssh -X -lusername 0.0.0.0Replace 0.0.0.0 with the real IP address of the client, and username with your username. The -X option tells ssh to forward X11 events.
You should now have a login shell.
Let's set up those shell scripts. On your client machine, create a file somewhere in your $PATH and open it up in your favorite text editor. All you need here is: #!/bin/bash
export ESPEAKER=0.0.0.0:16001
exec xmms
exit
Now chmod +x it to make it executable.
On the server, the script you will want is:#!/bin/bash
esd -nobeeps -tcp -public &
exec rxvt -e ssh -X 0.0.0.0 exmms
exit
Again, replace 0.0.0.0 with your ip address and rxvt with your favorite x terminal emulator. Replace exmms with the name of the script you created on the client. chmod +x it.
Testing it:
Now, kill all instances of esd and xmms on all machines.
Run the script you made on the server machine. A terminal will pop up asking for your password. Type it in. (Once I RTFM and figure out how to make ssh connect without a password, I will add that procedure here as well.)
Xmms should pop up. Go ahead and play a song.
Let's check top:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
14288 maedhros 13 0 552 552 456 S 1.9 0.8 0:05 0 esd
14290 maedhros 10 0 1740 1736 1268 S 0.5 2.8 0:13 0 ssh
Ah... much better. :) Enjoy the fruits of your labor.
Comments and corrections are welcome. If you've read this far, it means you have a lot of determination. :)
...Refer all complaints to /dev/null
avoir fun :)
~psi42