10.5 Using mumble - some notes
All my development and testing of Mumble was done using my FTdx101D.
Audio source - receiver audio output
My FTdx101D has three possible sources of receiver audio to feed into the USB audio adapter.
- Rear panel: The 6-pin data connector. This appears to have output only from the Main receiver.
It has a fixed level. The front panel and CAT audio gain controls have no effect.
- Read panel: A 3.5mm stereo jack socket with Main and Sub receiver outputs separate on
the two pins . It has a fixed level. The front panel and CAT audio controls have no effect.
- The front panel headphone socket. This combines the output from both receivers.
The front panel audio gain controls and CAT audio gain controls are effective.
Therefore, if you want to use Mumble remotely, with access to both receivers and have separate control
of AF gain, then you have to use the headphone socket to feed the USB adapter.
In some radios, an attenuator might be needed.
In addition, piWebCAT's audio gain swapping feature (on VFO swap) can only work using CAT
audio gain control and so would have to use the headphone socket.
Audio source - receiver microphone input
My FTdx101D has a menu option to select SSB microphone input between front panel microphone socket
and rear DATA connector. Some CAT software packages do not offer this switching as a CAT option.
However, this switching is available as a CAT command ( EX0101110; EX0101111;) and so
piWebCAT can be configured to control it, either with a toggling button or a pair of buttons (your choice).
Laptops / tablets - received audio quality
- Connection of RPi mumble client to transceiver.
As stated in sections 10.2 and 14.6 it is important to install the USB audio adapter
'without any conversions'. Otherwise on a quiet channel, the background noise is suppressed
to an unhelpful warbling noise. In addition, I disable any noise reduction by Mumble.
- Audio quality is not helped by speaker quality on some devices.
- Some of the available configuration facilities on the mumble clients appeared to make
no difference to audio quality and so my configuration has them unused or disabled.
Laptops / tablets - transmitted audio
- Microphones: The built in microphones are not as good as using an external microphone.
I purchased an excellent USB desk microphone from Amazon (EIVOTOR £23).
This produced very good signal reports.
The microphone has a built in volume control which was a deliberate choice.
The FTdx101D has mic. gain and processor adjustments (which are repeated in piWebCAT).
The mic gain control is not effective when feeding audio into the rigs rear DATA/RTTY connector
and so a gain control on the microphone is useful to optimise compression and ALC levels.
(The configuration options in mumble client provide for preset level adjustment but are inconvenient
for operational adjustment)
- I do not use Mumble's noise reduction and compression facilities.
Transmitted audio delay
There is a delay of perhaps 600ms between spoken audio and outgoing transmission.
I find that this makes real time self monitoring almost impossible. The delayed feedback has a bizarre
effect on my speech!! I therefore used the rig's recording facilities to record test audio via Mumble.
I could then transmit this on dummy load and monitor on a separate receiver.
Received audio delay
There is a similar audio delay on received data.
Its effect on tuning the receiver is not really noticeable.
It is probably largely offset by the simultaneous small delay between the piWebCAT tuner
and the response of the receiver.