How to set up a Mumble conference with ALSA.
You'll need to verify you have a few things installed before you can get started:
Verify that you have these modules by looking in mod/ for their filenames (mod_portaudio.so and mod_conference.so)
Also, make sure they're enabled in autoload_configs/modules.conf.xml.
Initially all you'll need to do is setup a conference, which is configured in autoload_configs/conference.conf.xml:
Mine looks like this:
There's probably 'problems' with this, but it works perfectly for me, so pundits please update this example if you spot any errors.
As you can see, it's a basic conference, but with some key differences: the RATE is quite high (48khz), but this is because Mumble (on my system) uses this samplerate. Using the same samplerate not only avoids resampling, but also improves stability (no jitters, or crackles). Take note of this setting though for later.
Assign an extension to this conference, and test it out. My dialplan entry looks like this:
In our case, the conference is configured as 'default', and there is no conference named 'hydway', so .. it works. But I think if you have more than one conference, you should point your dialplan at it properly.
The Portaudio plugin must also be setup, and the configuration is located at autoload_configs/portaudio.conf.xml. Mine looks like this:
Again, take note of the 'sample-rate' parameter, we want it to match both our conference and our mumble client.
ALSA asoundrc or asound.conf
Notice the 'indev' and 'outdev' values as 'cloop' and 'ploop' in the portaudio setup. These devices will be created using the snd-aloop ALSA module by adding (or creating) the following to /etc/asound.conf:
Effectively, this will connect 'asnoop' with 'ploop', and 'amix' with 'cloop'. When audio is piped into asnoop, it'll come out of ploop. The same goes for the other two. (You can name these whatever you want; mumbleAplayback/mumbleAcapture and mumbleBplayback/mumbleBcapture for example may make more sense.)
In this configuration, everything runs through dmix and dsnoop. This isn't required if your samplerates match. To freeball it, change the 'type' field to 'plug', and remove the ipc_key lines.
In case your freeswitch is currently running, connect using fs_cli and issue:
Now, while still in fs_cli, list your portaudio devices to verify it is using our new loopback devices:
If configured correctly, it should look something like this:
The entries to note are 'ploop' and 'cloop', entries 15 and 16. At the end of each line you'll see 'r,o' which means 'ringer, output', meaning this device is where your portaudio endpoint will both ring on and send output to. The next line has an 'i' at the end, meaning the endpoint will use this device as input.
The 'Loopback' entries (6 and 7) are possibly unusable. I haven't found any way to directly address the subdevices ('2,0,0', '2,0,1', etc.) Luckily, it picks up our handrolled PCMs, which is good enough.
If you've made it this far, it gets much easier. Get/build/install Mumble. I'm not going to explain how, their website should help you out.
Once you have Mumble built and running on your server (using Xorg or Xvnc), open the settings via Configure->Settings, and check the Advanced box in the bottom left.
Select Audio Input on the left-side menu.
Your devices (amix/asnoop) probably won't appear in the dropdown. If they do, select them. If they don't, don't worry, we'll fix that in a minute.
Under Transmission, set Transmit to Voice Activity. Adjust your Compression settings (I always suggest using Speex codec for compatibility with all Mumble clients, which may be achieved by selecting a Quality level below 45.5kbit. If it stays on CELT, your Mumble client probably wasn't compiled with Speex. I -highly- suggest recompiling with support for both, unless you have control over -every- Mumble client which this configuration will communicate with; otherwise you may not 'hear' what they say). Tune your Audio per packet as you like as well. I've found that when speaking to a murmur server running on my LAN, this can be set to the minimum (10ms) without any issues. It also improves responsiveness to do this, but higher settings may be required if you're connecting to a server off-site.
Switch to Audio Output on the left-side menu.
Default Jitter Buffer may be set quite low, I use 10ms. Output Delay also. Again, for longer range Mumble links, higher levels may be required on these two fields.
Switch to Messages on the left-side menu.
These are at your own discretion. Basically every message which has an audio-generating alert associated with it will be broadcast over the conference. This bothered me, so I disabled all message notifications. (Text-to-speech is sorta cool, but believe me, it gets old really fast on a conference!)
You may want to finish tuning your setup, but for great victory, click OK to save, and close Mumble.
Mumble manual device configuration
If your 'amix' and 'asnoop' PCM devices didn't appear in your Audio Input and Audio Output device selection fields in Mumble, some configuration hacking is required. Open ~/.config/Mumble/Mumble.conf in your favourite text editor, and locate a section which looks like this:
... now, change it to look like this:
Save, close, restart Mumble. Easy, right? Sure, but the next time you open Configure->Settings and click Apply or OK, you'll have to do this all over again. In my case, the section itself was removed from the config file entirely, I just re-added it. Other than this inconvenience, it works perfectly. And once running, you should have little or no reason to reopen your configuration anyway, right? :)
Connecting it together
If you've managed all of this, connect to any server you like in Mumble. If anybody speaks to you on there, you won't be able to hear it (if you have speakers or a headset connected to your FreeSWITCH server at all, you weirdos) because Mumble is routing directly into our Loopback device, which is tied, on the opposing end, to our mod_portaudio instance.
Go back to fs_cli and issue the following command:
...with your conference extension in place of '*94'. If all is well, you should see the 'lips' of your FreeSWITCH-controlled-Mumble-client turn red with fabulous activity-- briefly.
In the terminal where you executed Mumble, note the sample rates it is using for both input and output. Configure your conference and/or portaudio to match, unless you're satisfied by dsnoop and dmix's resampling.
Now to test both ends:
Connect to the same mumble server from another computer, as usual. Pick up your SIP phone (or whatever you have connecting to FreeSWITCH, softphone, iax phone, whatever,) and dial into your conference. Talk into each, and listen with the respective other. If you have latency, adjust buffering accordingly.
At this point, you may wish to set snd-aloop to automatically load on system startup by adding it to your /etc/modules file.
I'd also like to request input on methods to do the following:
If there are better solutions, please comment. Otherwise, once/if the Autoconnect patch is accepted on Mumble upstream, instructions will be adjusted accordingly.
I stole the snd-aloop and asoundrc idea from this: http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge