$70 all in one mumble server and wifi

[jtweigandt]

OK I uploaded the picomm document into resources under sound.. It has a step by step of how to roll your own. Hoping to upload the actual sd image today, but not sure if the board will accept a 2 gig tar file. If not, I may have to find other means to host the image for download. Can still contact me off forum and I would probably burn onto an 8 gig or higher micro sd sent to me with a SASE.

 

[Amiers]

Google drive can hold it and will prolly out live us all.

 

[Mark Harris]

I suggested something like this at our community theatre and the technical boss was not interested. He prefers a PTT system (currently using Uniden walkie talkies - it's a small theatre) so that you don't have continual noise in the headsets. Problem is, he starts talking before he's finished pushing the damn button so you're sitting in the booth wondering if that "-ts!" was actually "Go lights!" or what. We got him giving his commands twice for one show but he's gone back to his old habits [sigh]

Am I reading this right that you can do this with PTT? Seems to me full duplex means constant bi-directional, but I am only an egg when it comes to this stuff.

 

[jtweigandt]

Yes you can set any and all stations to ptt. In our case we leave the stations on continuous and use headsets which can mute the mic but leave the audio live, so you're always ready to recieve. We left the walkie talkies behind for precisely the thing you were talking about here. The voice quality is incredible. You have to try it to believe it. It eliminates the accidental vox problem, and the talk too soon problem, along with an exponential increase in the voice quality. The earbud "mute" switch for phones doesnt function properly, but headsets and usb headsets with a true mute button or switch does work. On your phone, if you are using it for a station, there is an icon (lips) that you press for the ptt if you are not using a headset with mute.

 

[Rob Kettridge]

This is looking quite interesting. Been playing around with it today using an old mac mini as a server and bridge between existing wired comms and the mumble network. All working as should, but there's one niggling issue, which is that the audio from the mumble network gets onto the comms line, but then because it's on the comms line ends up being transmitted back to the mumble network. This would be fine but the delay between the two is about a quarter of a second so by the time it's done two hops it's hearing yourself a good half a second after you speak. Anyone got any ideas how to cancel this out at all?

 

[Amiers]

Echo cancellation

 

[Rob Kettridge]

The echo cancelling feature appears to be missing from the mac version. Is it good enough to deal with this sort of issue? May have to boot camp the machine to give it a go...

 

[Amiers]

Well when I used mumble it worked for me.

So idk maybe give it a try.

 

[jtweigandt]

The echo cancelling feature appears to be missing from the mac version. Is it good enough to deal with this sort of issue? May have to boot camp the machine to give it a go...

Pretty sure the mumble echo cancel is watching for a packet tagged with you as origin, and then doesn't play it for you.. So in theory.. you talk on the comms.. they inject into the mumble client.... if the client is filtering packets correctly, the hello comes in from the comm, goes out to all the other mumble clients, but shouldn't be returned via your mumble client acting as the bridge. It should be filtering packets that originated there, so the downstream to the comm doesn't get the echo.

Problem would be with hello from another mumble client.. goes to the bridge mumble, out to the comms, delayed so it comes back to the bridge, looking live not digital. Bridge injects back to mumble, and the mumble clients downstream are getting an echo.

Only saving grace would be if I'm wrong and the echo cancel is just a simple temporary mute of the mumble client earpiece. Then it would work if the mute time was long enough. Just one way to find out I guess.

 

[jtweigandt]

OK a little World experience here that may help some others if we’re trying this. I found out that you need to pay particular attention to microphone set up. If you overdrive, mumble will clip, and that divides your transmission up into many many small IP packets, which will for a few seconds seem to cause drop outs on the other stations. I thought I was getting Wi-Fi drop outs, but as it turns out that’s been pretty solid. But Mike overdrive and packet clipping is very annoying. It was a difficult diagnosis, but a very easy fix if you just run the audio set up carefully I had one station that was just driving me nuts

 

[jtweigandt]

More real world thoughts Rasp pi3 acting as wifi router/ mumble server. HP thin clients x2 1 hard wired 1 wifi.. good as gold. Pizero wifi clients x2. 1 pc client, 1 pi 3 client. Needed the wifi repeater to cover the stage area for the pi zeros. Running another repeater to cover arrivals/parking lot. Pi3 as server has all the oomph you need to run 6 to 7 clients continuous. Wifi router server component rock solid. Pi zero clients wifi show the strain in a full house of patrons without the wifi repeater. Will auto reconnect, but get lots of reconnects. With the repeater pi zero clients are solid. Pi 3 as client in the box office working over repeater solid performance. Had one pi zero that got flakier and flakier over the last week. Final conclusion.. just a bad MB. Logitech 820e dect headsets, absolutely rock solid extremely long range in our building, even when the building fills up (house about 550) Can get all the way out in parking lot from booth. Also ran my cell phone as a client while on parking duty. All in all once I got the repeaters in, this is good. Have been running the units continuous, with some random forced restarts for the last couple of months as a burn in... Only 1 pi zero was not up to that, but it may have failed me anyhow. No sd card failures in this time period.

 

[maldridge]

I think its been several years since I joined and made my first (and at this point, other) post, but figured I'd drop in. While my exploits in the theatre have slowed to a crawl, I do now work with a robotics competition where we use Mumble as a comms solution to handle queuing of teams on and off the fields, separate channels for staff in different areas, and other features that we've now grown to depend on. We ditched the walki-talkies for the reasons already stated in the thread and haven't looked back.

Some interesting perspectives about mumble stability: The most recent competition I was at I had the good fortune to have access to some very high end RF test gear (a keysight fieldfox if you're curious) where we identified over 500 discrete RF sources while walking around. These were all in the 2.4 and 5Ghz bands, but predominately in the 2.4Ghz band. To be clear, these were sources operating in infrastructure mode; I estimate there were easily another 2k cell phones sitting on the building's distributed antenna system. The entire time I was talking on a headset plugged into a cheap android phone and my signal did not drop. Our wireless solution was the classic Linksys 54G router, which was sitting at one end of the roughly hockey-rink sized arena. I had good voice quality the entire time, the system was stable, and we did not have serious issues in keeping it running over a 4 day continuous interval. We operated the system with at peak 45 simultaneous voices on the line and the server remained lightly loaded. While we were using a Linux laptop to host the server, a Pi could easily handle this load (Mumble just routes streams, it doesn't do any real processing on them).

I've also done the Pi route for testing, but since I help maintain a Linux distribution I've been willing to do some more... interesting... things with my system images. Right now I've got it down to a 15 second boot before the server is available and I'm almost happy with that, but I'd like to get it a little faster.

Bottom line: If I was back working with a high school/middle school group tomorrow with no budget and a stage in a gym, I would not bother with telephone based intercoms or even the surprisingly cheap Que-Com system, I'd bring a junk laptop and a wifi router.

 

[jtweigandt]

Thanks for some more real world data. No problem at all using the dusty laptop for a one off. Reason for doing it on the pi was that for 70 bucks, it's there and running all the time, even if the dusty laptop guy graduated or moved on. Theres something to be said for having some permanant infrastructure, especially in settings where documentation and training is often generational folklore, rather than the printed word.

 

[darinlwebb]

Please keep working on this! Doing a write-up on Instructables, or maybe even a github repo, could get you more feedback from beyond the theatre community.

I've got a Pi 2 laying around, I might give this a go too.

Regarding the power-cycle issue, that problem has been solved before, and there are plenty of guides for setting up a simple power switch that triggers a soft-shutdown.

 

[jtweigandt]

So just an update.. I completed the run of "Catch me if you can" in the spring quite nicely. No problems at all with the pi router/mumble server. I had a mix of pc and pi stations with Logitech H820e dect wireless headsets.. the logitech headsets are da bomb. flawless.. I had a bit of trouble with my pi stations when re booting would hang at the GUI load sometimes and have to be re flashed. The pc thin client stations were perfect. Finally cracked the reboot hang the other day.. I designated 128 meg instead of 64 meg to the video memory. I think it was testing various video configs headless and over ran it's capacity. I also designated "wait for lan" on the boot sequence. Now I've had them up and down probably 20 times.. no problems.. Tonight I'll be running the parking lot with a battery pack pi zero in a little case on my belt. Here we go Mame!! we go comm on the cheap, because indeed Life is a banquet, and most of us poor bastards are starving. have had 7 stations running 500 seat theatre, and the picom server never so much as blinked.

 

[Rob Kettridge]

I'm still fighting with this issue of hearing yourself back from the wired comms a delayed time later. I'm using a standard Tecpro comms pack to do the interfacing between the two networks and using the sidetone control to null out the echo which is working to some extent but not enough. The other thing I'm finding is that a lot of cheaper phone headsets leak audio from the speaker lines to the mic line, which is usually fine if all your audio is in sync but it's causing people on the wired comms to hear an echo of themselves as it leaks across. Unplugging the offending headset or disconnecting the mic line removes this issue.

 

[jtweigandt]

I ran into the cheap earbud echo as well.. read about how they are wired/ supposed to be wired and the evolution of the phone earbud plug definition, but still couldnt wrap my head around why they leak.

If you have a friend with really good skills you could make an electronic switch.. It detects out going mumble signal, and you could set it to clip the return during the duration of the mumble transmit plus x milliseconds (tunable)

could even do it in software with a pi

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

I don't have the skills.. but someone does..

 

[Doug Lowthian]

Do you have the documentation for this available somewhere? Not able to find it on this site, but I could be looking in the wrong place.

Thankls in advance!

 

[jtweigandt]

Do you have the documentation for this available somewhere?

Documentation is on this site under the resources tag at the top. (forums wiki media resources) Picomm document 1.1 There's also a link to my google drive of the pre configured
sd image to burn for your pi3.. Google will throw an error, since you can't preview it, but you can go ahead and hit the download button
It's big... a couple gig, but it's a complete machine image.

Literally plug and play from there. Burn the image to a micro sd (google can help you with the burn) Plug in to a pi3 boot up, and the wifi will be picomm wifi password ... theshowmustgoon all smalls The doc also has enough info for you to "roll your own"
if you wanted to mod it or just wanted to DIY

you can communicate with it over the wifi, or via ethernet wired if you are plugged in. 192.168.0.1 address.. Can access with mumble app on iphone brumble app on android., or any device running a mumble client.. linux, windows, mac.

Would love to hear back if we get more of these rolling.

 

[Jay Ashworth]

BTW, all: I was looking for other things on Amazon the other day... and I found a whole bunch of boom-mic bluetooth headsets that would probably work well with this setup... including active noice cancelling ones...