mumble icon indicating copy to clipboard operation
mumble copied to clipboard

[Feature request] Push to talk controlling a USB COM port (for ROIP applications)

Open mike6000 opened this issue 8 years ago • 10 comments

Mumble could potentially be able to gain a large new radio user community by adding support for ROIP (radio over IP). The streaming functionality is already very good for radio (have done tests)

Request: we need to control an I/O port on a USB COM port: when someone pushes push to talk (PTT): a signal could then please be sent to the server and this signal can be routed to a USB COM port. Even better: the signal is routed to a File source and a sink can read the data. Alternatively a localhost solution via UDP / TCP could be implemented. It would be appreciated if the dev team could look into supporting PTT control of external IO pin.

mike6000 avatar Oct 25 '16 07:10 mike6000

You can simulate this by using the existing SocketRPC support for mute and deafen: https://github.com/mumble-voip/mumble/blob/master/src/mumble/SocketRPC.cpp

In Mumble 1.3.x (current Git master) you can invoke SocketRPC via the command line:

$ mumble rpc mute # Mute Mumble
$ mumble rpc unmute # Unmute Mumble

etc.

mkrautz avatar Oct 26 '16 21:10 mkrautz

Hi thanks for suggestion.

Summarized: We want a way to switch a radio transmitter on and off based on PTT status of the users that is available in the Murmur server. If one of the users pushes PTT, the radio transmitter is switched on and audio is transmitted. When he releases the PTT, the receiver is on. The radio (mumble client) would stream the received audio to a Murmur server room and receive transmit audio from the server room.

All the Mumble clients would be connected to the Murmur server. The radio would be on a low bandwidth 4G connection or similar. Radio could probably be a mumble client, (needs to be startable on the cmd line)

The idea is that the server can be on the internet with good fiber connection, while the radio is connected as a client on a low bandwidth connection as a client.

The COM port PTT status on / PTT status off would be needed on the radio side because it could be used to switch an actual radio transmitter on and off.

I assume it is the Murmur server that would have this PTT Mute / Unmute status available? The info could be sent on a separate socket to a small program running on the same machine as the Mumble client. This small program could switch the transmitter on and off (simple transistor connected to a USB FTDI device on a COM port)

Can you suggest an example on how this could be achieved?

mike6000 avatar Oct 30 '16 10:10 mike6000

Rephrasing mike6000's request:

Every time someone speaks their icon lights up on the mumble client. They would like mumble to send a signal whenever any icon (as side from their own) is lit, and possibly a different signal when all icons are unlit.

Radio can't do transmit and receive at the same time, so they need a way to know if anyone is speaking. When someone is speaking, they can use the signal from mumble to switch the radio over to transmit mode.

It would let the ham radio community have nice networks without shelling out for specialty proprietary digital radios.

On moble, so apologies for any spelling mistakes.

EmperorArthur avatar Nov 03 '16 22:11 EmperorArthur

As a note, Mumble already has this feature, it's just not exposed to user space.

The Audio Output option, "attenuate applications by... while other users talk" has the information mike6000 is after.

EmperorArthur avatar Nov 21 '16 00:11 EmperorArthur

@mike6000 If you're running linux, I recently added a dbus interface to the client to poll for a list of actively speaking users. This could be used by an external program or script to detect when someone is talking and generate a PTT signal for a ROIP application by polling the client 10-20 times/second.

@EmperorArthur In my use case, I looked at using the volume attenuation information as a signal that someone else in the room was talking, by actually polling my application's current volume level. While it seemed to work, it was fairly brittle to rely on volume levels, so I wanted to pipe the signal out over dbus. When I dove into the client source code, it wasn't clear how that signal was actually computed. The way I read the code, I was paranoid that the logic would glitch out if more than one user was talking simultaneously. As it turned out it was easy to get a list of all actively speaking users, so I just piped that out instead.

I think a much more slick approach would be to extend the positional audio plugin system to call a function when the actively speaking user list changes. Then folk could implement whatever exotic PTT IO they need to do inside a plugin.

sgtnoodle avatar Dec 27 '16 07:12 sgtnoodle

Good day everyone. Is this feature request still open? I'm looking also for this option in the Raspberry Mumble client. When someone is talking (a stream is active) then there will be a GPIO pin active. So it will be the base to create a circuit for switching PTT from my HAM radio. Hoping someone can make this possible in software. Regards, Alex

IntraxRadio avatar May 25 '17 17:05 IntraxRadio

I still need this functionality as well. I was planning on implementing it as an extension to the positional audio plugins, but I have higher priority work to do.

Since you're using a Linux based client, you could use the client's dbus interface to periodically poll for the list of actively talking users. You could probably poll it at 20Hz from a python or bash script. If you go that route, fair warning that the python dbus module has a memory leak that you'll notice running at 20hz for several hours!

On May 25, 2017 10:35 AM, "IntraxRadio" [email protected] wrote:

Good day everyone. Is this feature request still open? I'm looking also for this option in the Raspberry Mumble client. When someone is talking (a stream is active) then there will be a GPIO pin active. So it will be the base to create a circuit for switching PTT from my HAM radio. Hoping someone can make this possible in software. Regards, Alex

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mumble-voip/mumble/issues/2598#issuecomment-304072571, or mute the thread https://github.com/notifications/unsubscribe-auth/AJqg1ePblH_hVH4Prr1U6xk9_sL6HS0nks5r9bvWgaJpZM4KfpAD .

sgtnoodle avatar May 25 '17 19:05 sgtnoodle

@sgtnoodle Any news on the PTT detect via server API? It would be a real enabler if someone could implement this thru the positional audio plugin it would be great!

Also, DBUS as an interim solution sounds good. But do someone have some implementation example in Python for polling the dbus interface?

What property do I use to read the "actively speaking status" of the users? I found this https://wiki.mumble.info/wiki/DBus_Methods#getPlayerState list of methods.

mike6000 avatar Dec 12 '17 07:12 mike6000

Try this.. from Suvir.. https://github.com/talkkonnect/talkkonnect

totokadiw avatar Jan 26 '20 19:01 totokadiw

If you are willing to spend $150, you can get this functionality in hardware using a SignaLink USB. It acts as an audio interface between the pc and radio, and it automatically activates the PTT of the radio when input audio is detected. I am going to use this setup with a mobile radio, laptop, and starlink internet connection to get radio comms out to remote field teams.

walmartshopper avatar Sep 06 '23 18:09 walmartshopper