Transmitting via audio modem fails

[[e-mail]]

1. In the Beacon tab of the Preferences, check Enable Beacon and choose Manual for the rate.
2. Create an audio modem connection using a Digimode-4 cable and use the Test PTT button to compare that PTT is working.
3. Enable the audio modem connection.
4. Open the log.
5. Click the beacon button to manually send a beacon.
6. Notice that one of two things will happen. Either “Posting packet for transmit” will appear in the log but no transmission will be sent (the beacon is sent via APRS-IS, if such a connection is enabled), or else the packet is posted followed by “Audio modem willTransmit”, at which point the radio will be stuck in transmit until you quit QTH or turn it off.

‌

[Weston Bustraan]

1. Which PTT mode are you using and how is it configured? I assume it must be either Serial or Hamlib, since you mentioned clicking the “Test PTT”, and only those 2 can be tested.
2. When the radio is stuck in transmit, is it continuously transmitting a packet or does it transmit the packet followed by silence? Does it even transmit the packet audio at all?

‌

[[e-mail]]

PTT is using serial. Here’s a screenshot of the setup. This has worked fine for previous versions:

It seems to be just transmitting silence. When I do this while listening on my D74, the D74 indicates that it’s receiving a signal with a full S meter, but I don’t hear any audio.

[Weston Bustraan]

In the laters version 0.5.3, I moved the code that keys the radio closer to where the audio is queued for playback, to minimize the any potential delays. It should key the radio, play the audio buffer that contains the encoded packet, and then immediately unkey.

I tested with a serial adapter hooked it up to a multimeter to verify that, with the settings configured like your screenshot, the RTS pin transitions from -V to +V while the audio is playing and then returns to -V afterward.

The debug log message “Audio modem willTransmit” precedes the PTT keying, and the log message “Transmitted packet” occurs immediately after. If the latter fails, it would mean that audio device could not play the audio

‌

[[e-mail]]

I tested with 0.5.3, and I’m still seeing it get stuck in transmit. Here are the lines that appear in the log:

09:18:25.905 DEBUG APRSManagerImpl.transmit():147 - Posting packet for transmit
09:18:26.077 DEBUG APRSISConnection.onAprsPacketTransmit():249 - KI6HQT-10>APQTH1,APRS,TCPIP*:=3015.37N/09744.60W#PHG7030QTH.app experimental digipeater
09:18:26.188 DEBUG AudioModemConnection.willTransmit():266 - Audio modem willTransmit

Note that transmitting worked fine prior to 0.5.2.

[Weston Bustraan]

Do you still have the sampling rate set to 48 kHz? I’ll have to check my audio generation code, but I’m wondering if it is refusing to play the buffer due to a sampling rate mismatch. Can you check and see whether it has the same issue if the output sampling rate is set to 44.1 kHz?

It seems that Apple’s API is not calling my completion handler, for some reason

[[e-mail]]

Yes, I did. After setting the sample rate back to 44.1 kHz, it was able to transmit a packet successfully, no more stuck in transmit.

[Weston Bustraan]

Aha! Ok, that makes sense now. That is something I can fix

[Weston Bustraan]

So, I thought that maybe I had not implemented encoding audio output to 48 kHz. As it turns out, I was wrong; I had.

When you start the audio modem, it initializes the modulator and demodulator with the current sample rate of the output and input devices, respectively.

However, I was able to reproduce your experience by starting the modem and then changing the sampling rate with Audio MIDI Setup while the modem was running.

Is it possible that you have another app running that is changing the sample rate? Such as GarageBand or something like that? If the sample rate was changed while the demodulator is running that is definitely something that would cause it to not receive packets.

In v0.5.4, I added code to detect sampling rate changes, so if this is happening, you will now see log messages and the modem will reinitialize itself with the new sample rate.

[[e-mail]]

Anything is possible, but it seems very unlikely that any app that doesn’t have a reason to change the sample rate is doing so while it’s running and putting it back when it quits. In fact, I can’t even think of any way for that scenario to be happening, as the apps that are running while QTH is running are all the same every time. The only other apps which could conceivably have anything to do with the USB Audio Device input settings are the other radio apps (WSJT-X, etc.) that also use it, and none of them are running at the same time as QTH.

[Weston Bustraan]

I agree, it does seem unusual, but it would fit the scenario.

I’ve tested with the CM108 chipset in both 48 kHz and 44.1 kHz mode and both work to transmit. Perhaps there is something about the Digimode that requires it to run in 44.1 kHz mode?

I am interested to see what your logs say.

[[e-mail]]

In 0.5.4, when I attempt to enable the audio modem connection I get this error:

The log contains the following lines:

09:05:51.704 DEBUG AudioModemConnection.initReceiveChannel():192 - Init input device 44 USB Audio Device
09:05:51.707 DEBUG GoertzelDemodulator.init():203 - Sample rate 44100.0 filter enabled
09:05:51.962 DEBUG GoertzelDemodulator.APRSKit():485 - Audio queue is running
09:05:51.965 DEBUG AudioModemConnection.initTransmitChannel():235 - Init input device 44 USB Audio Device
09:05:52.006 DEBUG Bell202Modulator.init():123 - Using device: 44, Sample rate 44100.0

Nothing has changed in the connection settings from previous builds.

[Weston Bustraan]

Version 0.5.5 should fix the CAError. The CM108 device I was testing with happens to present itself to the OS as two devices. one input and one output. When I plugged a different CM108 device, that appears as a single device, I got the same error as you. As it turns out, attempting to register a property listener (sample rate, in this case) on the same device twice (input and output) causes the error.

[[e-mail]]

The CAError is indeed gone in 0.5.5.