Yaesu FT-710 Audio Setup with PipeWire on Linux

Updated 7.6.2026.

The Yaesu FT-710 HF transceiver contains a non-standard and possibly emulated CM-108 USB audio interface that allows working digital modes without any need for an external sound card. Simply plug the USB into your PC of choice and start going. Unfortunately, on Linux, some required parameters aren’t passed through to the sound system which cause issues with using it.

The primary issue is that PipeWire, the modern (as of 2025) default audio system on Linux distributions, defaults to a sample rate of 48000 Hz, which exceeds the capabilities of the built-in audio of the FT-710 at 44100 KHz. Unfortunately, the USB Audio Device reports that it’s compatible with 48 kHz, when that’s not the case. When this happens, the USB Audio Device starts disappearing and reappearing rapidly in Gnome Control Panel until you close any programs attempting to use it. I haven’t tested this, but the same should occur in KDE or any other desktop environment.

The easiest fix is to force the global sample rate of the entire PipeWire system to 44100 Hz by entering the following in a command line:

# pw-metadata -n settings 0 clock.force-rate 44100

From here on out, you’ll have to select your USB Audio Device in Gnome Settings (or KDE Settings), then point your app to use “pipewire” as the input and output device.

Here’s the fix if you never, ever want to deal with this issue again.

1. Identify the device

With the radio connected and powered on:

wpctl status

Find your radio’s audio interface under Audio → Devices. Note that many radios present themselves as a generic-sounding device rather than under the radio’s brand name — the FT-710, for example, shows up as a plain “USB Audio Device” backed by a C-Media USB audio codec chip. Note its device ID, then look up its vendor/product ID and its sink/source node names:

wpctl inspect <device-id> | grep -E "vendor.id|product.id"
wpctl inspect <sink-id> | grep node.name
wpctl inspect <source-id> | grep node.name

2. Pin the sample rate, if your device needs one

Skip this step if your device already negotiates a correct, stable rate on its own. Some radios’ USB audio interfaces have a real hardware/firmware limitation that only manifests at their advertised default rate. The FT-710 is one example: it advertises 48 kHz support in its USB descriptors, but has a clocking bug that causes the device to drop in and out of the OS roughly once a second when actually driven at 48 kHz — 44.1 kHz is stable.

If your device needs a specific rate, two settings work together, and testing showed both are required — a per-device rate pin alone was not sufficient to keep the FT-710 stable:

• Per-device rate pin. Add a WirePlumber rule matched by vendor/product ID, e.g. ~/.config/wireplumber/wireplumber.conf.d/51-fixed-rate.conf:monitor.alsa.rules = [ { matches = [ { device.vendor.id = "0x0d8c", device.product.id = "0x0013" } ] actions = { update-props = { audio.rate = 44100 } } } ] (substitute your own device’s vendor/product ID and required rate — 0x0d8c/0x0013 above is the FT-710’s C-Media codec)
• Permanent global clock-rate override. Add ~/.config/pipewire/pipewire.conf.d/44100-rate.conf:context.properties = { default.clock.rate = 44100 } A temporary, session-only equivalent exists (pw-metadata -n settings 0 clock.force-rate 44100), but it does not survive a WirePlumber/PipeWire restart or a reboot — it is only useful for a quick test. Use the permanent config file above so the fix actually persists; this was confirmed the hard way during testing, when a WirePlumber restart silently dropped a rate that had only been set via the temporary command, and the FT-710 promptly started dropping out again.Exact paths can vary by distribution — consult your distro’s PipeWire/WirePlumber documentation if these drop-in locations don’t apply to your setup.

3. Pin RigControl Web’s Backend Input/Output to the exact node

Create (or add to) ~/.config/alsa/asoundrc. Verify this is the path your system’s ALSA config actually loads — check the @hooks section of /usr/share/alsa/alsa.conf; some systems load ~/.config/alsa/asound.conf or plain ~/.asoundrc instead.

pcm.ft710_out {
    type pipewire
    playback_node "alsa_output.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-stereo"
    hint {
        show on
        description "FT-710 (pinned, 44.1k)"
    }
}
ctl.ft710_out { type pipewire }

pcm.ft710_in {
    type pipewire
    capture_node "alsa_input.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.mono-fallback"
    hint {
        show on
        description "FT-710 (pinned, 44.1k)"
    }
}
ctl.ft710_in { type pipewire }

Use the exact node.name values from Step 1’s wpctl inspect output for your own device — the strings above are the FT-710’s and will not match a different radio or a different machine. playback_node/capture_node bind this PCM directly to that one hardware node, bypassing PipeWire’s “default” indirection entirely regardless of what PipeWire currently considers default. The hint block gives the device a friendly label in RigControl Web’s device dropdown; name the pcm/ctl blocks and the description after your own device if it isn’t an FT-710.

4. Reload and verify

systemctl --user restart wireplumber pipewire pipewire-pulse
aplay -L | grep -A1 ft710
arecord -L | grep -A1 ft710

Both should list your new pinned device with the friendly description from the hint block. You can now use these devices in your apps.

Do I know why it’s this difficult? No. Hopefully this can be resolved in the desktop environment UI in the future.

Pipewire: how to set the audio sample rate for a device like a microphone

Freedesktop.org: WirePlumber

Reddit: FT-710 with FT8 in Linux (Debian/testing) – finally solved