Skip to content

Releases: kc2g-flex-tools/nDAX

Pipewire Latency Workaround

18 Aug 17:07
Compare
Choose a tag to compare

There's a known problem with pipewire's implementation of the pulseaudio pipe_source module that causes high RX latency if something isn't listening on the RX audio device all the time (for instance, wsjtx might work fine until the first time you transmit, then stop being able to receive, because it shut down the RX device while it was transmitting, and when it opened it again there would be a backlog of several seconds of audio).

I've been recommending that people with pipewire open a mixer app like pavucontrol because the level monitor would make sure that something was always reading from the device, but it should work pretty much as well to do it from nDAX directly.

This release adds a new option -consume, with values false, true, and auto. Setting it to true makes nDAX start reading from the RX audio device as soon as it's created, and discard the data. The default, auto, enables the behavior only if the PulseAudio "package_name" string contains "PipeWire".

Fix for stations with spaces in their names

17 Aug 16:56
Compare
Choose a tag to compare
v0.4-20240817.1

bump go versions

Enable DAX low-bandwidth mode

26 Jan 03:11
Compare
Choose a tag to compare

Since its inception, nDAX has used the default DAX audio mode, which is 32-bit floating point samples at 48kHz. This uses a bandwidth of about 1.64Mbit/s.

But it seems that Flex's own FlexDAX exclusively uses the "reduced bandwidth" DAX mode, which is 16-bit integer samples at 24kHz, which uses a bandwidth of about 468kbit/s, for a savings of 70%.

Since all Flex waveforms run at 24kHz, there should be no loss from the lower sample rate, and the loss of dynamic range should be minimal (the ADC is 16 bits to begin with).

Besides saving bandwidth (improving performance on weak wifi, cellular links, etc.), the low-bandwidth mode will probably also reduce CPU usage in most scenarios, since most applications want 8-bit or 16-bit data anyway, and converting from floating-point comes at a cost.

If you really need the high-bandwidth mode (a valid case might be receiving very weak signals with AGC OFF), it can be re-enabled with the -high-bw option.

Fix a build-from-source error

07 Oct 13:07
Compare
Choose a tag to compare
v0.2-20221007.1

bump go requirement in go.mod to 1.17

Increased platform support, Go upgrade

07 Oct 05:53
Compare
Choose a tag to compare

Builds for linux/arm64 (RasPi 4), darwin/amd64 (Intel Mac), and darwin/arm64 (M1 Mac) are now available. The mac builds require PulseAudio, and may not work at all. Bug reports (or success reports) are welcome.

SmartSDR 3.3.29 Discovery Fix

28 Apr 02:58
Compare
Choose a tag to compare

3.3.29 discovery packets were confusing flexclient. If you upgraded your Flex and nCAT and nDAX no longer connect, try upgrading to this version to get things working again.

I'm moving in stereo, you're shaking like tremolo

10 Nov 22:56
Compare
Choose a tag to compare

Two noteworthy changes in this version:

PulseAudio devices will now have their "description" set based on the station name and slice letter. This helps with operating multiple radios or multiple slices... at least if your apps (or your mixer) display the description and not just the name.

There is a new -tx-channel option that allows creating a stereo sink and using just the left or right channel for the TX audio. Normally nDAX creates a mono sink, which works just fine — apps either open it as mono, or they open it as stereo and output the same data to both channels. But there are some ham apps that insist on opening their outgoing sound device as stereo, even if it's mono, and sending audio on only one channel. In this case, PulseAudio helpfully converts stereo to mono by mixing the two channels. Since one channel is silent, that means you get -3dB amplitude, or -6dB power. If you run into an app that just can't manage full power output, try running nDAX with -tx-channel left and see if that fixes it (if you get zero power, then try -tx-channel right). This should also work fine for most apps that worked in the past, but the default remains mono.

Small usability improvements

14 Jul 15:51
Compare
Choose a tag to compare

Two features in this one:

  1. nDAX will detect a PulseAudio server that is too old (less than v12) and exit with an informative error, instead of exiting with a confusing error and leaving the pulse devices in a half-configured state. This should help out people running on old versions of Ubuntu or Raspbian.

  2. There is now a -udp-port option to control the UDP port that nDAX will use to listen for VITA-49 packets. Normally it's recommended to keep this at the default (which will use any available high port, avoiding conflicts) but users with firewall or tunneling requirements might want to control the port themselves.

March Marchness

08 Mar 03:16
Compare
Choose a tag to compare

Been a while since we've had a release. Two notable changes in this one:

  • There is now a packet reordering buffer, which adds a small amount of latency on receive (16ms by default) but allows dealing with UDP packets that arrive out of order. Packets which are dropped (or re-ordered further away than the length of the buffer) are also handled, by duplicating a previous packet, which causes a slight audio glitch but is better than having a total drop-out. This improves RX stability significantly on WiFi, especially for digital modes. The buffer can be disabled in case of any trouble with -packet-buffer 0.

  • nDAX now checks whether its PulseAudio devices already exist on startup. If they are owned by another running instance of nDAX, it will exit with an error, to avoid conflicts. If they were created by a previous instance of nDAX which crashed without cleaning up correctly, it will remove them before starting up. This has been on the TODO list since April 2020, but now it's done.

No More Resampling

16 Nov 00:38
Compare
Choose a tag to compare

This release changes from using PulseAudio's module-null-sink for TX and RX audio to using module-pipe-sink for TX and module-pipe-source for RX. This has some advantages, namely:

  • The [INTERNAL] Flex RX Loopback and [INTERNAL] Flex TX Loopback devices, which used to be necessary, no longer exist and no longer clutter up your audio device selection.
  • nDAX is no longer in charge of synchronizing clock domains between the rate that audio samples arrive from the rig and the rate that PulseAudio consumes samples from the null-sink and makes them available to the monitor device.
  • Several hundred lines of code were removed, including the resampler PLL algorithm (which was complicated, received many tweaks, and was never quite right).
  • CPU usage is lower as nDAX no longer does floating-point math on each block of samples.
  • Users of SSTV and MFSK image modes should notice less "wobbling" in received images.

A few small configuration changes may be necessary upon upgrading to this release:

  • The -source and -sink option names have swapped places. They were originally (questionably) named from nDAX's perspective based on the loopback devices, instead of the user's perspective. Now there is only one perspective. If you are using the default flexdax.rx and flexdax.tx you don't have to change anything, but if you are starting nDAX with a script you will have to adjust your options. I felt it was better to break things a little bit now than to keep the confusing names forever.
  • The source device for received audio is no longer forced to have .monitor at the end — e.g. the default PulseAudio source will now be flexdax.rx, not flexdax.rx.monitor. You will likely have to re-select your audio source in wsjt-x etc., since the remembered source name won't exist anymore.
  • The -debug-timing option has been removed since it controlled something that no longer exists.
  • The -latency option probably doesn't do anything anymore — your apps are now in charge of the size of their own audio buffers. This is generally a good thing. The option is retained in case tweaking the source-side buffer size is useful for debugging, but you are recommended to leave it at the default.

Thanks for coping with these changes and as always please report any problems using the Issues tab.