No RX capability? about freedvtnc2

[xssfox]

No worries. I'll close this for the moment. If I can find out the exact cause I'll try to figure out which upstream project to raise the problem with.

[xssfox]

Try saving your config with the save command then running --no-cli --log-level DEBUG and provide the logs here. I haven't checked running this through jack. You could try running the tune command and a recording or listening to it to make sure it's generating a nice clean signal.

[iqw1345]

For additional context, the main audio server that I am using is pipewire, but I am using JACK's capabilities to manually run audio to where I want in this case. I have configured freedvtnc2 to use "pulse" as the input and output audio. That way, when I run the radio, I can start freedvtnc2 with the following:

PULSE_SINK=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo PULSE_SOURCE=alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo freedvtnc2 --input-device pulse --output-device pulse --kiss-tcp-port 8001 --mode DATAC1 --log-level DEBUG

This is out of habit from dealing with fldigi and direwolf.

As requested, I have attached logs of both instances trying to communicate with each other, but to no avail. I tried pinging freedvtnc2-2 from freedvtnc2-1.

freedvtnc2-2.txt
freedvtnc2-1.txt

I've also attached what the audio configuration looks like in this case using qjackctl with each tnc communicating with the other.

It's not shown in the above picture, but I didn't see a tune command, but I assume you meant to run the test_ptt command. I played test_ptt into my headphones and the audio output sounded clear.

Please let me know if there's any additional information needed from me.

[xssfox]

I'm not entirely sure what the problem is. I know i've had issues in the past with dynamically changing the inputs and outputs on pyaudio apps before using qjackctl before. I think this might be due to a clock change occurring that pyaudio/portaudio can't handle? I'm really not too sure tbh. I was certainly able to replicate your issue using my pipewire test box. For testing you can work around the issue by creating a sink device first and telling freedvtnc to talk directly to that.

pactl load-module module-null-sink sink_name=freedv_testing
freedvtnc2 --output-device "freedv_testing Audio/Sink sink" --input-device "freedv_testing Audio/Sink sink Monitor"

This worked for me, you can either run two of these or just one (the modem will happily RX it's self which is handy for testing as you don't need two instances running)

There's probably not a lot more I can do though.

[iqw1345]

Interesting, that works for me too. I appreciate the help and thanks for the project!