Audio modem connections don't receive packets by default

[[e-mail]]

I’ve been working on this one for several days, but haven’t been able to fully narrow it down. Since I’m not making progress, I decided to file it as-is and update it later as I get more information.

1. Have an APRS-capable HT on hand.
2. Set up an Audio Modem connection.
3. Confirm that the connection’s audio input is working by monitoring it with Garageband (or another app that can monitor sound inputs) while sending a beacon from the HT.
4. Enable the connection.
5. Send another beacon from the HT.
6. Notice that the computer can hear the packet, but QTH doesn’t decode it.

It is possible to get QTH to start decoding, and once that’s done it works fine until you quit the app and relaunch it, at which point the problem reappears. I haven’t been able to figure out exactly what it is that makes packet decoding start working, but this is a serious bug that I thought I’d better put in what I have now rather than waiting until I eventually figure it out completely.

[Weston Bustraan]

I don’t get a lot of APRS over RF in my area, so here is the way that I test the Audio Modem to ensure that it is still working properly:

1. Install Soundflower or Blackhole. More details about those here: Decoding APRS packets with an SDR
2. Download the WA8LMF Test CD audio files
3. Start QTH.app and configure an Audio Modem connection with an input of “Soundflower (2ch)”
4. Start the Audio Modem connection
5. Load the audio file in Audacity
6. Set Audacity’s output to “Soundflower (2ch)”
7. Hit play in Audacity
8. Watch the log for packets to come in

I find that QTH.app generally can decode over 900 packets from the test CD. For comparison, Direwolf can decode closer to 1,000 with some extra tricks.

If you can hear the audio with something like Garageband, then I would suggest making an audio recording of it so that you can replay it. Once you have an audio, you can try feeding it into QTH in the manner described above.

You can also compress it to an AAC or something and send it to me and I can test it.

‌

[Weston Bustraan]

Also, can you describe how you have the Audio Modem configured, in particular the devices you have selected for the input and outputs? Also, can you confirm which device Garageband is configured to record from?

When you start the connection, QTH should log the ID and name of the devices it is using for input and output to the log file. Can you check there to make sure that those are what you expect?

[[e-mail]]

Here’s a screenshot:

The “USB Audio Device” is my Digimode-4. I’m quite certain that this is set up correctly as it does work. Even when QTH isn’t decoding I can watch the monitor bar and see it jump as packets come in when I have the connection enabled. The input device is logged twice in the log file, and the output device isn’t logged. I’ve never had any trouble with packet sending, though.

I don’t actually know how to use Garageband (or audio software in general)--I was just following instructions I found from a web search on how to monitor audio input. I know I succeeded at that, because I can hear it, but when I tried to record a sample I couldn’t get it to work. Or at least, I couldn’t get an AAC out of it. I threw the whole Garageband project up on my web server. It’s a 10MB file, so the sound is in there somewhere. I let it record for about half a dozen packets. http://www.orange-road.com/APRS Sample.zip

This really needs an APRS capable HT to send packets from. Not just so you can have a packet on demand, but so you can be sure that the packets are decodable. One of the things I’m using my D74 for when testing this is to see if it could decode an incoming packet--if not, QTH wouldn’t necessarily be able to either. I know they can be a bit pricey, but if you’ve got any HT and an iOS device you can use a Mobilinkd TNC3 with aprs.fi as well. They’re only about $125.

[Weston Bustraan]

I do have two APRS-capable devices, a Yaesu VX-8DR and a Byonics TinyTrak AIO. I’ve tested with these devices in the past, with success. I just don’t test with them often, because they tend to produce a single type of packet, usually a Mic-E encoded packet. I used the Test CD as a baseline because it contains a wide variety of different packet types with varying amounts of noise.

I’ve also done testing with Direwolf where I connected my Mac running QTH to a Linux machine running Direwolf and YAAC. Audio in and out to audio out and in on the other machine.

Fortunately, one the hams in the beta test lives near me and he tells me he is putting up a digipeater in a nearby town, so I should have a better stream of data to test with in the near future.

[Weston Bustraan]

That Garageband file will work. I am getting the same intermittent results as you are.

A while back, I had to rip out the AudioKit framework I was using, and code to the low level CoreAudio API. I likely introduced a bug back then. And it probably fooled me into thinking everything was OK because it happened to work when I tested it.

[Weston Bustraan]

Findings from the last couple days:

RF Sanity Check setup:

• Packet source

  • Yaesu VX-8DR
  • Manual beacon when I press the button
  • Packet type: MicE

• Packet decoder: QTH.app Audio Modem

  • Baofeng UV-5R
  • Connected to MacBook headphone/mic jack using BTECH-APRS-V01 cable
  • Squelch off on radio
  • Audio Output: External Headphones
  • Audio Input: External Microphone
  • Adjusted volume so meter is peaking at 90%

• Result: 2 packets sent / 2 decoded

• This was the setup I used to develop the decoder a couple years ago, and it appears to still work.

Direwolf Decode

• Packet source: KI6HQT1.wav (Garageband Recording)
• Packet decoder: Direwolf atest -F 0 -P A  -h KI6HQT1.wav
• Result: 6 packets decoded
• Clearly, Direwolf’s implementation is superior to anything else out there
• Direwolf’s error correction algorithms were disabled

Mobilinkd Decode

• Packet source: KI6HQT1.wav

  • Playing from Audacity to USB Audio device (Griffin iMic)

• Packet decoder: Mobilinkd TNC2

  • Connected iMic audio out to Mobilinkd TRRS jack (speaker TRS pinout matches up to Mobilinkd TRRS pinout)

• Result: 2/6 packets decoded

• Used this to get an expectation of what to expect with a software decoder that isn’t Direwolf.

QTH.app Audio Modem - Audio File, Soundflower

• Packet source: KI6HQT1.wav

  • Playing from Audacity to Soundflower loopback

• Packet decoder: QTH Audio Modem

  • Audio Input: Soundflower (2ch)

• Result: 2/6 packets decoded

• Oddly enough, these were a different 2 packets from the TNC2

javAPRS Goertzel49-w_emphasis_0

• Packet source: KI6HQT1.wav
• Packet decoder: javAPRS Goertzel49-w_emphasis_0
• Result: 2/6 packets decoded
• This is was the implementation that I based my Swift port on

javAPRS PreclockingDemodulator-w_emphasis_0

• Packet source: KI6HQT1.wav
• Packet decoder: javAPRS PreclockingDemodulator-w_emphasis_0
• Result: 6 packets decoded

‌

Conclusions

• My initial hunch seems to have been wrong. I was thinking that there was a sampling rate or bit rate mismatch. If that was the case, the RF Sanity Check test should not have worked.
• There seems to be something about the first 2-3 packets in the audio recording that cause prevent them from being decoded properly by the Goertzel algorithm and whatever algorithm the TNC2 is using.
• I was thinking that 964 packets out of the Test CD was good enough, but I really like the results that both Direwolf and the PreclockingDemodulator achieve. I will have to look into these algorithms an see if I can understand the methodology.

‌

[Weston Bustraan]

Update:

Good news: By adding a lowpass filter and a pre-emphasis filter, I can decode 6 packets out of the sample audio

Bad news: For some strange reasons, my initial filter implementation is far too slow and cumbersome to be usable. Makes the processor really have to work.

‌

[[e-mail]]

Update for 0.5.1: no noticeable change. Sometimes it will decode some packets, but mostly not. For testing I’ve got a D74 with a Diamond whip antenna sitting on my desk about 15 feet from the Comet GP-1 my FT-897 is using. Packets sent from the D74 are not decoded. Packets received by both radios are not decoded by QTH but usually are by the D74. There are some cases where packets aren’t decoded by either, presumably from stations just a bit too far away.

[Weston Bustraan]

Have you tried with the new emphasis filter on or off?

[[e-mail]]

I didn’t realize that it was something that could be turned on or off. I went looking for the control and found that the default was on, so my previous report was for on. Further testing with the filter turned off, as well as with it on, shows no noticeable difference.

[Weston Bustraan]

I am wondering if you have discovered and tried a particular feature of QTH yet.

If you start the Audio Modem connection, and then open the configuration panel while it is running, the Audio Input Monitor at the bottom of the panel should display your current incoming sound level.

When I connect my Baofeng, I open the panel up and the turn the volume control dial on the radio until the green bars are about halfway up the meter.

If you see no green bars, then either it is not receiving any audio, or the input level is too low

If you see yellow or red bars, then it could be that the audio level is too high and the audio could be clipping.

Actually, if you wouldn’t mind, could you take a screenshot of the panel when it’s running? (Cmd-Shift-4-Space will let you screenshot just the window and drop the image on your Desktop)

‌

[[e-mail]]

Yes, I’ve been using that all along. Here’s a screenshot:

I have the volume set so that the monitor fluctuates between three and five green bars from background noise. This morning QTH as been decoding for a few minutes, and I noticed that when a packet is decoded the level always drops to two bars for the duration of the packet, then continues fluctuating. When a packet comes in that I can hear (listening with the radio volume turned up) but isn’t decoded, the level drops to 1 bar. I don’t remember this level drop happening for the previous version.

[Weston Bustraan]

The level calculation is actually not something that comes from my code, but rather it is a property of CoreAudio.

However, the level dropping to 1 bar is consistent with the audio sample that you sent earlier.

Here is the waveform of the packets that QTH has trouble decoding:

The waveform does drop almost to silence after the packet.

Later, in the same audio sample, there is another waveform, which QTH can decode:

‌

‌

‌

[Weston Bustraan]

I tried a test today with the Garageband sample that you sent previously.

I plugged in my Griffin iMic (USB souncard) and routed a cable from the speaker out to the mic in. I then set GarageBand’s output and QTH.app’s input both to the iMic. So basically, anything played out the iMic would be looped back into the mic input.

I found that, the 6dB filter was critical. I also confirmed this by turning off the filter in QTH and instead changing the EQ to ramp from 0dB at 1200Hz up to +6dB at 2400Hz. This is effectively the same filter being applied by QTH, but instead being applied by Garageband. In both cases, whether the filter was applied by QTH or GarageBand, QTH was able to decode all of the packets present the recorded audio.

I also tested what happens when the audio level was turn down so far that it doesn’t even register a single bar on the input level meter. It still managed to decode all the packets from the file.

I wondering if maybe my 44kHz filter might be faulty. Can you try going in to Audio MIDI Setup.app and changing your USB Audio Device to 48kHz instead of 44 and see if that works?

[[e-mail]]

No, it doesn’t. However, after a fair bit of testing the last couple days I have found a difference from the previous version. In the older versions, decoding would never work when I launched the app. I would then spend time fiddling with controls, and after a while it might start working (I still have no idea of it was anything I did that made it start working). If it did start working, it would then continue to decode packets for as long as the app was running.

With the latest version, it sometimes decodes packets right from the start, it sometimes starts decoding after the first few packets are received, without me doing anything, and it sometimes refuses to ever decode packets. Once it is decoding packets, it usuallys stops decoding after approximately two minutes or 1-7 packets decoded and then never starts decoding again.

Also, on rare occasions it decodes packets for extended periods. This is harder to test, as it requires QTH to be in a good mood at the same time I don’t need either my radio or my VHF antenna for anything else. However, I was able to leave it running earlier today while I ran some errands. Over a period of 186 minutes it successfully decoded 267 packets before I needed the radio for something else.

I’ll stress again that the problem isn’t that it’s not decoding as many packets as it possibly might, the problem is that most of the time it won’t decode any packets at all. I still haven’t been able to figure out what makes it work, because it clearly can work.

Addendum: I’ll keep trying with the audio in set to 48kHz, in hopes that some change will reveal itself with more extensive testing.

[Weston Bustraan]

I got some interesting results this evening: I’ve been using either my Griffin iMic or the built in MacBook audio jack for most of my testing. I did some reading on the Digimode-4 and found that it uses the C-Media CM108 chip. I remembered that I bought a cheap one of those a while back and started testing with it.

And.. discovered that I am getting results similar to yours, where it sometimes will decode and sometimes not. I haven’t had this experience with the other audio devices I own. But at least it gives me a way to replicate your experiences. I think I have another CM108 somewhere. I will see if I can dig that out and see if I get similar results.

I will also do some research and see if there is something about the CM108 and its associated audio driver that makes it finicky. Or perhaps it needs to be initialized in some way.

[Weston Bustraan]

For comparison purposes, have you used the Digimode-4 with other ham radio software on your Mac? Like Direwolf or Fldigi?

[[e-mail]]

Yes, I’ve used it with WSJT-X, Js8call, fldigi, and Winlink Express (the last running in Crossover), and it works fine with all of them.

[Weston Bustraan]

Ok, well, I guess that shoots down the faulty Mac audio driver theory. At least several of those are open source, though, so I can compare their audio capture strategies.

I’ll keep trying, but I will admit I’m starting to run out of ideas. I’m having difficulty replicating your experience; in particular, with the addition of the emphasis filter, I’m having difficult getting it to NOT decode packets. I will continue to use the CM108 device to more closely mimic your setup.

[[e-mail]]

Let me know if you need any more sample audio. The previous sample was pretty short, and as I mentioned the current build does tend to work initially and then stop working. Maybe a longer sample would help.

[Weston Bustraan]

The latest build (0.5.3) has some additional debugging added to it. It will log when the audio queue starts and stops, in case the audio queue is stopping for some reason. It will also log if there are any timeline discontinuities.

It operates a bit differently between processing an audio file versus streaming from an audio device. In the case of the audio file, it has one, large, single buffer to process, whereas the audio stream is processed in small chunks. So, for consistency, I generally will route a cable from the output on the soundcard to the input and the play the audio out with something like Audacity.

I have it set up now such that I can route the audio from my larger 2m antenna to the input of either of my CM108 devices. I have 2 more CM108-based USB audio interfaces arriving on Monday. So, far, I’m not experiencing the same issues as you are, with any of the audio devices I have. I am planning on reaching out to the beta test group to see if anyone else is testing QTH’s audio modem. We need more data from more than just you and I.

Aside from Winlink Express, all of the applications that you mentioned use the PortAudio library to capture audio. I looked into the PortAudio source code and I can see that they are accessing the audio devices at a lower level API than I am. They are using Apple’s AudioUnit API, whereas I am using Apple’s AudioQueue API that sits just above the AUs. I could change the code to access the lower level API, or even potentially use the PortAudio API, but before I make any major change like that, I will need more feedback from other users to determine whether this is a widespread issue or just isolated to your configuration.

One test, you might try, if you have the ability: I set up both QTH and Direwolf to take input from the same audio device and then brought up the log windows side by side. Then I could see when DIrewolf decoded a packet and see if QTH did as well.

[[e-mail]]

I installed Direwolf as you suggested, and here’s what I found. First the good news: when both Direwolf and QTH are decoding, QTH actually does a better job. I only saw one instance (out of many dozens) of a packet Direwolf could decode that QTH couldn’t, while QTH did a much better job when two packets arrived at almost the same time. In that case either QTH decoded both and Direwolf decoded only the first, or QTH decoded one and Direwolf didn’t decode either.

The bad news is that when QTH isn’t decoding, Direwolf still decodes just fine.

[Weston Bustraan]

Well, that certainly is good and bad news. In my experience, Direwolf usually just edges out QTH. Direwolf has a print out that looks like ___|||||_. Generally, if there are 4 or more vertical pipes, usually both apps decode it, but when it is 3 or less, QTH sometimes fails. This is because Direwolf runs multiple decoders in parallel with different emphasis levels and picks from the winners. QTH runs a single decoder.

Are you getting any new messages in the log? i.e. any “Timeline Discontinuity” or “Audio queue is stopped” messages?

[[e-mail]]

No, I’m not seeing either of those. Also, Direwolf is showing 5-7 vertical pipes (and in one case, 6 plus a colon) for various packets when QTH isn’t decoding. Many of these are from fixed locations such as digipeaters that QTH can decode just fine when it is decoding.

[Weston Bustraan]

Version 0.6.0 is my latest attempt to fix the decoding issue. When you get a moment, can you check if it resolves this issue?

[Ken Hagler]

Will do. The Mac Pro I had been using died over the weekend, so I’ll need to get it set up with my MacBook Pro.

[Ken Hagler]

Okay, I got QTH 0.6.0 installed on my MacBook Pro and working with my Flex-6400 using Audio Modem. I’ve seen it decode successfully, although I’ll need to watch it more to see how well it does over a long period. I did notice an oddity, though: the audio input monitor never moves. I can see the packets come in and get decoded, but the audio input monitor bar remains empty, never even a hint of green, regardless of what I set the level to or what’s being heard.

[Weston Bustraan]

Well, that’s good news so far. Crossing my fingers.

I bet the audio monitor got disconnected in the process of refactoring; I’ll check into it.

[Ken Hagler]

I’ve had 0.6.0 running for about twelve hours over the last few days, and it’s been able to decode consistently whenever it’s running. It looks like you did indeed fix the problem.

[Ken Hagler]

The audio monitor is indeed working again in 0.6.1.

[Weston Bustraan]

Excellent to hear! Sounds like I can close this then

[Ken Hagler]

This problem has come back in 0.6.4.

[Weston Bustraan]

To clarify, 0.6.3 did not have the problem, but 0.6.4 does now?

[Ken Hagler]

That’s right.

[Weston Bustraan]

Huh. Well that’s very strange. I made a few changes in the underlying code from 0.6.2 → 0.6.3, but none from 0.6.3 → 0.6.4

[Ken Hagler]

I did only use the audio modem briefly in 0.6.3 (it wasn’t around very long), so it’s possible the problem was there too and I didn’t see it. The original audio modem problem, when it was implemented in Swift, saw it work occasionally and then stop working, so it might be the case that with 0.6.3 I caught it while it was working and didn’t use it long enough to see it stop working.

‌

[Weston Bustraan]

Working on cleaning up old tickets. Is this still an issue under 0.8.7?

[[e-mail]]

I’ve actually changed radios and am now using QTH with a Kenwood D710 via KISS TNC.