TX becomes unresponsive after some time

[ogruetzmann]

TX becomes unresponsive after ~2h of use, 100% CPU on one core

I'm using TrackAudio 1.3.3 on Manjaro Linux (kernel 6.14), and I'm encountering an issue where TX becomes unresponsive after extended use (~2 hours).

Symptoms

• I can still hear other pilots clearly
• Pressing PTT does not reliably highlight the active TX frequency in the UI (sometimes only after a delay)
• Pilots report that their callsign is missing from my transmissions
• Eventually, I am unable to transmit at all
• htop shows one CPU core at 100% usage caused by the TrackAudio process

Affected versions

This behavior occurs with both:

• the trackaudio-bin AUR package
• and the official AppImage

Temporary workaround

Restarting the application restores TX functionality — but only temporarily.

Additional observations

The log file at
~/.local/state/trackaudio/trackaudio.log
continues to record PTT input events during the broken state.
(See around 2025-04-24 21:26:37.145 in the attached log.)

📎 trackaudio.log

Version history

I'm not sure if this problem also existed in previous versions.
I recently switched from Windows to Linux, and my only session on version 1.3.1 was likely too short for the issue to occur.

---

Let me know if I can provide more logs or test a debug build.

[pierr3]

Have you ever had this issue on Windows, or purely on Manjaro? Sounds like there might be a memory leak on this platform and I know where this could come from.

[ogruetzmann]

No, windows worked (and works) fine. A memory leak might be the case, although the memory footprint only rises by a few hundred megabytes. Do you need some more info?

[pierr3]

Think this might be related to some packet loss issues as well - has this kept occuring?

[pierr3]

Try the latest beta and let me know if it ends up happening again

[ogruetzmann]

I'll check next week.

[ogruetzmann]

Got to test 1.3.4 today, unfortunately it's still happening.

About timeouts, I guess you are referring to #305, I do indeed see timeouts, but different ones:
2025-08-12 22:12:06.561 INFO [262425] [LogFactory::LogFactory@33] [afv_native] ATCRadioSimulation:ATCRadioSimulation.cpp:645: Potential VoiceTimeout.. 1755029526 0

This looks a bit like #182, but I don't see unselected frequencies and still receive pilots without issue, only TX doesn't respond when I press my PTT key on an increasing number of transmissions.

The number of those log entries is quite significant.

trackaudio.log

[dead-tech]

Have you ever had this issue on Windows, or purely on Manjaro? Sounds like there might be a memory leak on this platform and I know where this could come from.

Not sure if this is related but I have had my TX become inactive after some time using the application on Windows. The application did not seem unresponsive though and I did not check the CPU usage.
The annoying thing about this issue is that in mini mode there is no way to see if TX is active therefore you would notice this problem only once pilots do not reply to your instructions.

[ogruetzmann]

Some additional info from my side:

• It seems to happen faster with multiple frequencies enabled, roughly 60 vs 30 minutes now.
• closing the app takes a significant amount of time in this state, so I guess either clean up or some queue that is being processed.

I was finally able to build an unstripped debug version, but doing a quick perf top, I couldn't make out any specific part.

[pierr3]

This is likely going to be an afv-native issue (underlying library) - I have not had reports of this on Windows or Mac, so it must be something with how the library interacts with Linux, could be a pulseaudio or ALSA thing too, which audio backend are you using?

[ogruetzmann]

I‘m currently using pipewire/pulseaudio. Can try ALSA next time I get a chance.

[pierr3]

Give ALSA a try, the underlying audio library had some issues with pipewire recently. Do let me know how that goes

[ogruetzmann]

Gave ALSA a go today, unfortunately it makes no difference.
For my next session I'm going to switch to X11, just to rule out any Wayland effects.

[ogruetzmann]

Just noticed that a new beta is out, I'll try that one as well

[ogruetzmann]

No luck and I'm running out of ideas on my end. But since I seem to be the only one running into this issue, I think this can be closed. I'll stick to one of the legacy clients and try new versions when they arrive. Unfortunately, pulling up a new instance every 30-90 minutes, depending on how much I transmit, is not an option.

Ping me if you have some more ideas.

[ogruetzmann]

An update from my end, I'm now using vacs with TrackAudio, which connects via websocket and triggers TX on TrackAudio.
This works, so it is not an issue with the audio backend.
What happens after long sessions is that I can't close TrackAudio without kill/pkill and I'm not able to set/change the PTT key. via the UI.

Closing TA hangs at 2025-12-29 22:27:40.674 INFO [68369] [{anonymous}::Exit@850] Awaiting to exit TrackAudio...
Log attached

trackaudio.log