starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

Support of variuous PTT hardware #2984

New issue

Open

opened 2026-02-20 22:16:09 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-20 22:16:09 -05:00

Owner

Originally created by @nckpln on GitHub (Apr 16, 2025).

Context

There are plenty of PTT apps exist on a market mostly for mobile devices and they already have existing hardware which meant to be used in scenarios similar to Mumble. Most of that hardware has APIs and protocols which are open and well documented such as PTT mics, headsets and buttons for Zello, NuovoTeam, RealPTT.

Description

Add support for PTT hardware

Mumble component

Client

OS-specific?

Additional information

I did a quick prototype using my AinaPTT Remote-Speaker-Microphone. In essence its just a BT headset with a serial port for buttons data. Documented both on Zello and Aina websites

So the simple python sketch which reads serial input and simulates a hotkey press for Mumble woks as a charm =)

import serial, keyboard

with serial.Serial('COM18', 115200, timeout=0.1) as ser:
    print("Connected")
    while(True):
        rxdata = ser.read(8)
        #print(str(rxdata))
        if rxdata == b'+PTT=P':
            print('PTT DOWN')
            keyboard.press("capslock")
        elif rxdata == b'+PTT=R':
            print('PTT UP')
            keyboard.release("capslock")

Would be great to implement it natively in Mumble app. I don't have experience with BLE stack so I don't know how much work is needed to add this, but serial port looks pretty simple and platform agnostic.

Originally created by @nckpln on GitHub (Apr 16, 2025). ### Context There are plenty of PTT apps exist on a market mostly for mobile devices and they already have existing hardware which meant to be used in scenarios similar to Mumble. Most of that hardware has APIs and protocols which are open and well documented such as PTT mics, headsets and buttons for Zello, NuovoTeam, RealPTT. ### Description Add support for PTT hardware ### Mumble component Client ### OS-specific? No ### Additional information I did a quick prototype using my AinaPTT Remote-Speaker-Microphone. In essence its just a BT headset with a serial port for buttons data. Documented both on [Zello](https://paidsupport.zello.com/hc/en-us/articles/26912026346253-Zello-PTT-Button-Partner-Technical-Integration) and [Aina](https://ainaptt.com/wp-content/uploads/2024/08/AINA_APTT_Communication_Protocol_v18_aina.pdf) websites So the simple python sketch which reads serial input and simulates a hotkey press for Mumble woks as a charm =) ```python import serial, keyboard with serial.Serial('COM18', 115200, timeout=0.1) as ser: print("Connected") while(True): rxdata = ser.read(8) #print(str(rxdata)) if rxdata == b'+PTT=P': print('PTT DOWN') keyboard.press("capslock") elif rxdata == b'+PTT=R': print('PTT UP') keyboard.release("capslock") ``` Would be great to implement it natively in Mumble app. I don't have experience with BLE stack so I don't know how much work is needed to add this, but serial port looks pretty simple and platform agnostic.

deekerman added the

labels

2026-02-20 22:16:09 -05:00

deekerman commented

2026-02-20 22:16:10 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Apr 16, 2025):

I am not aware of any standardized protocol for something like this. If there is indeed no standard protocol then this issue has a scope that is way to broad to be useful as it would be equivalent to "support all custom buttons found on any hardware".

That being said, if the buttons register to the OS as regular input events, then Mumble should already be able to bind them to shortcuts directly 🤔

@Krzmbrzl commented on GitHub (Apr 16, 2025): I am not aware of any standardized protocol for something like this. If there is indeed no standard protocol then this issue has a scope that is way to broad to be useful as it would be equivalent to "support all custom buttons found on any hardware". That being said, if the buttons register to the OS as regular input events, then Mumble should already be able to bind them to shortcuts directly 🤔

deekerman commented

2026-02-20 22:16:11 -05:00

Author

Owner

@Hartmnt commented on GitHub (Apr 16, 2025):

If there is indeed no standard protocol then this issue has a scope that is way to broad to be useful as it would be equivalent to "support all custom buttons found on any hardware".

Adding to this: In that case it could still be implemented using the Mumble plugin API by a downstream developer. It would just not be really viable for us to maintain it in the client itself.

@Hartmnt commented on GitHub (Apr 16, 2025): > If there is indeed no standard protocol then this issue has a scope that is way to broad to be useful as it would be equivalent to "support all custom buttons found on any hardware". Adding to this: In that case it could still be implemented using the Mumble plugin API by a downstream developer. It would just not be really viable for us to maintain it in the client itself.

deekerman commented

2026-02-20 22:16:12 -05:00

Author

Owner

@nckpln commented on GitHub (Apr 16, 2025):

I am not aware of any standardized protocol for something like this. If there is indeed no standard protocol then this issue has a scope that is way to broad to be useful as it would be equivalent to "support all custom buttons found on any hardware".

That being said, if the buttons register to the OS as regular input events, then Mumble should already be able to bind them to shortcuts directly 🤔

Its kind of standardized in mobile world. Apps on iOS and Android can not have access to keyboard input in background. So they came up with two ways of doing it: bluetooth low energy (BLE) service and good old serial port over bluetooth. The second one should be quiet easy to support. As I mentioned its quiet a few apps for PTT over Internet, so Mumble can be really good opensource alternative for it if it can support existing hardware.

@nckpln commented on GitHub (Apr 16, 2025): > I am not aware of any standardized protocol for something like this. If there is indeed no standard protocol then this issue has a scope that is way to broad to be useful as it would be equivalent to "support all custom buttons found on any hardware". > > That being said, if the buttons register to the OS as regular input events, then Mumble should already be able to bind them to shortcuts directly 🤔 Its kind of standardized in mobile world. Apps on iOS and Android can not have access to keyboard input in background. So they came up with two ways of doing it: bluetooth low energy (BLE) service and good old serial port over bluetooth. The second one should be quiet easy to support. As I mentioned its quiet a [few apps](https://ainaptt.com/guides-and-manuals-ptt-voice-responder-guides/) for PTT over Internet, so Mumble can be really good opensource alternative for it if it can support existing hardware.

deekerman commented

2026-02-20 22:16:12 -05:00

Author

Owner

@nckpln commented on GitHub (Apr 16, 2025):

If there is indeed no standard protocol then this issue has a scope that is way to broad to be useful as it would be equivalent to "support all custom buttons found on any hardware".

Adding to this: In that case it could still be implemented using the Mumble plugin API by a downstream developer. It would just not be really viable for us to maintain it in the client itself.

Oh that's a good idea! I haven't considered that one! =)

@nckpln commented on GitHub (Apr 16, 2025): > > If there is indeed no standard protocol then this issue has a scope that is way to broad to be useful as it would be equivalent to "support all custom buttons found on any hardware". > > Adding to this: In that case it could still be implemented using the Mumble plugin API by a downstream developer. It would just not be really viable for us to maintain it in the client itself. Oh that's a good idea! I haven't considered that one! =)

deekerman commented

2026-02-20 22:16:12 -05:00

Author

Owner

@Hartmnt commented on GitHub (Apr 16, 2025):

Its kind of standardized in mobile world. Apps on iOS and Android can not have access to keyboard input in background. So they came up with two ways of doing it: bluetooth low energy (BLE) service and good old serial port over bluetooth. The second one should be quiet easy to support. As I mentioned its quiet a few apps for PTT over Internet, so Mumble can be really good opensource alternative for it if it can support existing hardware.

Yes, this is what it looks like from a users perspective. I think the question that @Krzmbrzl proposes is more like: Do the various hardware implementations of such devices use a common logic e.g same serial port, same baud rate, same protocol.

Or do they all do more or less the same thing, while using slightly different protocols.

The latter would be less viable for us to support as we would have to constantly add/remove update single implementations. If they all "speak exactly the same language", we could add this to Mumble without contemplating maintainability.

@Hartmnt commented on GitHub (Apr 16, 2025): > Its kind of standardized in mobile world. Apps on iOS and Android can not have access to keyboard input in background. So they came up with two ways of doing it: bluetooth low energy (BLE) service and good old serial port over bluetooth. The second one should be quiet easy to support. As I mentioned its quiet a [few apps](https://ainaptt.com/guides-and-manuals-ptt-voice-responder-guides/) for PTT over Internet, so Mumble can be really good opensource alternative for it if it can support existing hardware. Yes, this is what it looks like from a users perspective. I think the question that @Krzmbrzl proposes is more like: Do the various hardware implementations of such devices use a common logic e.g same serial port, same baud rate, same protocol. Or do they all do __more or less__ the same thing, while using slightly different protocols. The latter would be less viable for us to support as we would have to constantly add/remove update single implementations. If they all "speak exactly the same language", we could add this to Mumble without contemplating maintainability.

deekerman commented

2026-02-20 22:16:12 -05:00

Author

Owner

@nckpln commented on GitHub (Apr 17, 2025):

Yes, this is what it looks like from a users perspective. I think the question that @Krzmbrzl proposes is more like: Do the various hardware implementations of such devices use a common logic e.g same serial port, same baud rate, same protocol.

Or do they all do more or less the same thing, while using slightly different protocols.

The latter would be less viable for us to support as we would have to constantly add/remove update single implementations. If they all "speak exactly the same language", we could add this to Mumble without contemplating maintainability.

Zello is the biggest player on the market, so most of the hardware are compatible with it, and then the rest of the PTT apps are trying to be compatible with hardware for Zello, so they have to follow the same protocols. Here is a list of Zello officially supported accessories, but you can find much more unofficial stuff on Ebay/Amazon by searching smth like "zello bt ptt mic".

As I mentioned in the first message, Zello provides an extensive guide on a partner hardware integration, including SPP (Serial Port Profile). In essence it just sends fixed message on a button press and release events. Mumble app could just record it during button assignment process, the same way it does it with the regular keyboard input. Buy doing it there is no need to hard code those button messages.

The exact serial port assignment is the OS feature: COM* in Windows and /dev/rfcomm* in Linux, but it has to be user selectable in app anyway. The baud rate is standard 115200, but again can be specified by user.

I can have a look at BLE accessories, since most of dedicated PTT buttons use BLE and not SPP for energy saving purposes.

@nckpln commented on GitHub (Apr 17, 2025): > Yes, this is what it looks like from a users perspective. I think the question that [@Krzmbrzl](https://github.com/Krzmbrzl) proposes is more like: Do the various hardware implementations of such devices use a common logic e.g same serial port, same baud rate, same protocol. > > Or do they all do **more or less** the same thing, while using slightly different protocols. > > The latter would be less viable for us to support as we would have to constantly add/remove update single implementations. If they all "speak exactly the same language", we could add this to Mumble without contemplating maintainability. Zello is the biggest player on the market, so most of the hardware are compatible with it, and then the rest of the PTT apps are trying to be compatible with hardware for Zello, so they have to follow the same protocols. Here is a [list](https://zello.com/hardware/headsets-buttons-mics/?connection-type=bluetooth&device-subtype=speaker&device-subtype=headset&device-subtype=button&device-type=android&device-type=ios&device-type=pc) of Zello officially supported accessories, but you can find much more unofficial stuff on Ebay/Amazon by searching smth like "zello bt ptt mic". As I mentioned in the first message, Zello provides an extensive guide on a partner hardware integration, including [SPP (Serial Port Profile)](https://paidsupport.zello.com/hc/en-us/articles/26912026346253-Zello-PTT-Button-Partner-Technical-Integration#h_01HYE39THBQNC3PB33SC09NC8A). In essence it just sends fixed message on a button press and release events. Mumble app could just record it during button assignment process, the same way it does it with the regular keyboard input. Buy doing it there is no need to hard code those button messages. The exact serial port assignment is the OS feature: COM* in Windows and /dev/rfcomm* in Linux, but it has to be user selectable in app anyway. The baud rate is standard 115200, but again can be specified by user. I can have a look at BLE accessories, since most of dedicated PTT buttons use BLE and not SPP for energy saving purposes.

deekerman commented

2026-02-20 22:16:12 -05:00

Author

Owner

@erentar commented on GitHub (Oct 3, 2025):

Yes please

@erentar commented on GitHub (Oct 3, 2025): Yes please