Klaatu from the GNU World Order oggcast has released the second version of the Linux Multimedia Sprint, with another gig or so of freely licensed art, sounds and whatnot.
If you are using mumble for a show and you would like to set up a listening room, where listeners can listen to your show, talk amongst themselves but not interfere with the show itself, here is one way to set it up.
Right click on the root channel, click add and create your main channel, which we’ll call it ‘Pointless’ for this example.
Right click on the Pointless channel, click add to create a subchannel, which we’ll call ‘People With No Lives’.
Enter Pointless and right click on People With No Lives and click ‘Link’. This allows users in both channels to hear and talk to each other across the channels.
Next, right click on Pointless and choose ‘Edit’. Click on the ‘ACL’ tab. Click ‘Add’, untick ‘Applies to sub-channels’, but make sure ‘Applies to this channel’ is selected. Under the ‘Group’ pulldown, choose ‘out’. In the ‘Speak’ row, tick the box in the ‘Deny’ column. This prevents users in other channels from speaking into the channel you are editing the rule for.
This will leave you with your main channel, Pointless, a subchannel, People With No Lives. People With No Lives can hear Pointless and talk amongst themselves, but Pointless will not hear the chatter from People With No Lives.
If you do not want people within the subchannel to be able to speak with one another, add an ACL to the subchannel, group ‘in’, toggle deny speak. I should note here that trying to deny speak from the main channel while applying it to subchannels seems to completely supress anyone in the subchannel. They can neither speak nor hear the linked audio.
I’m sure there are a half dozen permutations of these rules which will do similar things. If your show’s cast is stable enough that dealing with group registrations is a viable option, you are probably better off going that route.
I managed to get mumble streaming through icecast this morning and felt I should get a few notes up about how it can be done. There are better places to learn about setting up icecast and mumble, but there doesn’t seem to be much information written up about how to use them together.
If you’re running linux and are thinking about doing some oggcasting/podcasting or are having a virtual meeting which you might wish to make available for general listening, perhaps you’ll find these notes to be at least slightly useful. I’ve been involved in several discussions over the last several years regarding the best way to record a *cast and stream it at the same time, and while I can’t state with authority that this is the “best” way, it is at least _one_ way…and it’s not bloody talkshoe. This is still fairly rough, and I’m no expert in any of this, so it’s likely you’ll want to play with various settings after you’ve got it running to get better quality out of it. Your mileage may vary.
For those who aren’t familiar with it, Mumble is a VOIP client similar to Teamspeak or Ventrilo, generally used for gaming. Best to just click here and read about it from the horse’s mouth. If you want the short version, you can run your own Murmur server if you like, and have roundtable discussions using the Mumble client. Audio quality is generally excellent.
Version 1.2.3 of Mumble, which was released recently, has a built in recording function with a number of options. You can record a session either as one ogg, wav, flac, or au file. You can also record each participant in a session to their own track, which would make the editing process a little cleaner if you needed to edit out noise or match audio levels. So, if all you’re wanting to do is record a *cast, then Mumble should do the job for you quite well.
I was curious about how you could also stream it live while the recording was being done. The setup of this initial success has plenty of room for improvement. But for posterity’s sake, here’s how I managed it:
[EDIT: I have managed to get this running on a single computer. The (somewhat ugly) method I used is detailed at the bottom of this post.]
* A working Icecast2 server
* A Murmur server (wherever)
* 2 computers with the Mumble client installed – 1 for you to chat on (which I’ll call TALKER), 1 to do the streaming (which I’ll call STREAMER), which needs pulseaudio installed on it for this method
* The svn trunk version of Darkice
I’m going to leave off explaining the setup of Icecast, Murmur and Mumble. Plenty of places have better explanations than I can provide about those topics. The archlinux wiki is a good place to start. Murmur and Mumble are very straightforward, and setting up Icecast for this isn’t difficult. Just make sure to set a password for the “source” user in your Icecast config as Darkice will be using that for the stream.
You will need to create a null sink in pulseaudio on STREAMER. Enter
pactl load-module module-null-sink sink_name=stream on the command line to create a virtual output named “stream” which doesn’t actually point at a sound card, but will allow other programs to capture that output before it’s dumped. Pulseaudio will automatically create what it calls a ‘monitor’ for that output which you can use as input for another program, in this case it will be called “stream.monitor”. Darkice will be using stream.monitor as it’s audio input.
Once you have created the null sink, set the audio output on STREAMER’s Mumble client to the pulseaudio null sink (Settings->Audio Output, System = PulseAudio, Device = Null Output). It would also be a good idea at this time to ‘mute self’ on STREAMER, or even remove the right for it to transmit if you are admin of the Mutter server, simply to ensure that it doesn’t pass along any unwanted audio.
Next you’ll need to install Darkice. At the time of this writing, you’ll need to grab the subversion trunk in order to use pulseaudio. Sooner or later this won’t be an issue as the code makes it way into stable releases. I needed to install libvorbis-dev, libtool, and libpulse-dev as well as subversion and the normal development tools.
Pull the dev code for Darkice with this on the command line:
svn checkout http://darkice.googlecode.com/svn/darkice/trunk/ darkice
cd darkice and run
./autogen.sh on the command line. Pay attention to it’s output, and it will tell you if you’re missing anything critical which will need to be installed. Once it’s done, type
make to build Darkice.
I needed to add one line to three of the source files in order to get this to compile. If it fails for you, try adding this line
#include cstdio (please note! you need carats around cstdio, but they are being stripped and it’s too bloody late at night for me to care enough to search for the answer. They should look like this.) to each of these files in the src directory: PulseAudioDspSource.cpp, SerialUlaw.cpp, JackDspSource.cpp. Simply open each of those files in a text editor and add that line below the copyright notice and the other line which starts with #include.
Once you’ve added those, go back to the darkice directory and try ‘make’ again. When you get a successful compile, run ‘make install’ as root to complete the installation.
Now, cd back to your home directory and copy the file ‘/usr/local/etc/darkice.cfg’ to someplace convenient for your user to work on it. /home/YOU/darkice.cfg is perfectly reasonable.
Open your copy of the darkice.cfg file and under the first section, titled [general], change
duration = 60 to
duration = 0 to continuously encode the stream.
Next, look for the section titled [input]. Change the ‘device’ entry from ‘/dev/dsp’ to ‘pulseaudio’, and add the line
paSourceName = stream.monitor at the end of the input section. When you’re done, it should look something like this:
# this section describes the audio input that will be streamed
device = pulseaudio # OSS DSP soundcard device for the audio input
sampleRate = 22050 # sample rate in Hz. try 11025, 22050 or 44100
bitsPerSample = 16 # bits per sample. try 16
channel = 2 # channels. 1 = mono, 2 = stereo
paSourceName = stream.monitor
Check ‘man darkice.cfg’ for more options.
I’m streaming to Icecast2, so I just commented out the icecast-0 and shoutcast-0 entries. In the [icecast2-0] section, fill in your server address, password (for the ‘source’ Icecast user) and anything else you need or wish to change. I also changed my ‘mountPoint’ to ‘stream.ogg’. In the end, it should look something like this:
bitrateMode = abr # average bit rate
format = vorbis # format of the stream: ogg vorbis
bitrate = 96 # bitrate of the stream sent to the server
server = myserverip # host name of the server
port = 8000 # port of the IceCast2 server, usually 8000
password = sourcepassword # source password to the IceCast2 server
mountPoint = stream.ogg # mount point of this stream on the IceCast2 server
name = DarkIce trial
# name of the stream
description = This is only a trial
# description of the stream
url = http://www.yourserver.com
# URL related to the stream
genre = my own # genre of the stream
public = no # advertise this stream?
localDumpFile = dump.ogg # local dump file
Finally, the moment of truth. Get your Mumble clients on TALKER and STREAMER connected to your Murmur server. Fetch some friends to jeer at your accomplishment and have them connect as well.
On streamer, run
darkice -c darkice.cfg on the command line.
If it’s successful, you should see these lines:
Using config file: darkice.cfg
Using PulseAudio audio server as input device.
Using PulseAudio source: stream.monitor
You will probably receive this warning, as well:
Could not set POSIX real-time scheduling, this may cause recording skips.
Try to run darkice as the super-user.
I haven’t solved this issue yet. Running darkice as root doesn’t completely solve the problem because it won’t talk to the stream.monitor input.
But, the bottom line is that if you’re seeing this message, you should be in business. Find some sap to connect to http://yourip:8000/stream.ogg, hit record on TALKER’s mumble client and talk to your friends.
[EDIT: The section belows details the steps I needed to use in order to make this work from a single machine. YMMV]
There are a couple of problems I initially had trying to run this one machine. Mumble was not happy running a second instance in a single X session, even when launching the second instance as a different user. It was “stealing” the certificate for my normal user and re-logging me in under that account in the second mumble session, which would log me off of the first session. This was also a real pain when I went to add my normal mumble user as an admin on my local server. I ultimately ended up needed to start a second X session, run mumble and log in to the superuser account there and set the permissions on my normal mumble account. There’s a ‘-m’ flag which I’ve seen referenced which is supposed to allow you to log in without using your certificate, but that didn’t work for me.
Launching a second instance of mumble under a different user on the same X session was also giving pulseaudio fits. There might well be some hocus pocus (read: permission stunt) that I can pull to fix that problem, but given the nature of the first problem, I haven’t bothered looking into this.
However, you can start up a second X session with a different user on the machine, and use it that way. At the moment, I need to do it with the root account (which is horrible, yes, I know) but I suspect that this is an issue with the catalyst drivers and my dual monitor setup rather than a necessity in general. It does, however, have the benefit of solving the real time scheduling error from Darkice.
At any rate, the setup is similar to using a second machine.
startx -- :1 on a virtual console to start the second X session, start mumble and point the output to a null sink, and then run darkice out of the second user account.
The Linux Multimedia Sprint project has released it’s first batch of content, consisting of various openly licensed sounds, images, and other assorted multimedia goodness. Read all about it and browse the archive here.
What could be more relaxing than wiling away the time building a model ship.Â How about taking it down the local pond and sailing it around with a dozen of your closest friends?
Just watch out for these people…
The MWCI is a model warship combat club. They build 1/144th scale replicas of warships, load them full of bb’s and then zip around ponds shooting at each other. They game in shallow ponds so that the ships can be retrieved, patched up, and sent back to the battle.
Sound fun? Events are held year round all over the United States. There are other model warship combat clubs, but I haven’t found anything outside of North America. Canadians might be in luck, although websites for their activities are slim.
update: The Australians are in on it, too.
Brian Koehler has a great page on the hobby, including video from past events and pictures of ship building.
(P.S. Thanks to Kevin Inscoe for reminding me about this. We went to an event years ago but lost track of the local club. It’s a great way to spend an afternoon with the family.)
Science at work, obviously. Nottingham University has done us the service of creating The Periodic Table of Videos,Â where you watch the building blocks of our universe go boom.
Take potassium, for example…
And now, I’m testing the rss feeds, which may or may not be working correctly.
People do this for fun?