Choppy transmit audio when using Dire Wolf on macOS

[johnboiles]

Running Dire Wolf 7d3c1d1 on macOS 13.1 with AIOC c65a3f3, most transmitted packets are choppy. A clear error is thrown in Dire Wolf when this happens Transmit timing error: PTT is on 3558 mSec too long.:

And sure enough the radio output looks (and sounds) weird and choppy:

Possible this is a Dire Wolf bug but I don't get this same thing when using my built-in soundcard. My relevant Dire Wolf config is:

ADEVICE "AIOC Audio" "AIOC Audio"
ARATE 48000
PTT /dev/cu.usbmodem5a031bca1 RTS -DTR

[johnboiles]

Seems like my $10 RTLSDR dongle + SDRAngel is doing significantly better than my AIOC + Baofeng + Direwolf at decoding packets, so I'm also suspicious there's something going wrong with the input audio also. But I'm not sure how to debug this.

[johnboiles]

I'm also seeing some core audio processes take up a ton of CPU. Perhaps that's a hint? Perhaps there's something on a single core and CPU constrained? I'm on a MacBook Pro 2021 w/ M1 Max (10 cores). Overall CPU usage is ~30%

[johnboiles]

I killed the CAReportingService process (it was using 14gb RAM!!!) and tried again. The first 4 packets failed, then all subsequent ones worked.

[skuep]

Odd! Do you happen to know, that the message "PTT is on ... too long" is supposed to mean? For now I cannot make sense of those lines.

Regarding the choppy audio: Have you programmed the firmware file v1.0.0 from the GitHub release page or do you have one of the beta devices I sent out a while ago? If the latter, can you try updating the firmware to v1.0.0. I remember there being some issues very similar to choppy audio that I also noticed (although only on very few of my AIOCs).

[johnboiles]

I'm not sure what it's supposed to mean. But I suspect what's happening is that the audio is slow to output (and thus sounds choppy), making the whole packet take too long, and that's why this error is firing.

I'm running on firmware SHA c65a3f3 built from my local machine. That's two commits on top of v1.0.0. If you think there'd be an environment difference I could flash your pre-built hex.

I ordered my boards from jlcpcb on 1/2, so I was probably on commit caed7f6d3 for my hardware.

[lysol]

FWIW, I ran into this same issue on MacOS, switched over to Ubuntu, and didn't have the issue. Same AIOC, same firmware (1.0.0), so I doubt the issue is the AIOC itself. More likely a driver or library issue.

[johnboiles]

@lysol thanks for the note. Setting up a arm64 Ubuntu VM in UTM.app and running Direwolf there worked just fine. Took a beat to find the right device names but after that it's been flawlessly. I needed:

ADEVICE plughw:AllInOneCable,0
PTT /dev/ttyACM0 RTS -DTR

It's a little clunkier perhaps then running natively on macOS since you have to configure/start a VM, but it worked flawlessly.

So this bug could be in portaudio, Direwolf, the sound drivers being used for AIOC, or in the AIOC firmware (unlikely since it works fine on other platforms). I guess the next step to investigate on macOS would be to play+record sound via the AIOC cable with other tools and see if other tools can reproduce it.

[skuep]

I'm running on firmware SHA c65a3f3 built from my local machine. That's two commits on top of v1.0.0. If you think there'd be an environment difference I could flash your pre-built hex.

There shouldn't be any difference. It may be possible that it could be related to your build environment being different, but that is just a long shot. Though confirming that the problem is present with the exact binary that I built could be somewhat helpful in narrowing down the problem. Gotta find a macOS machine first though.

FWIW, I ran into this same issue on MacOS, switched over to Ubuntu, and didn't have the issue. Same AIOC, same firmware (1.0.0), so I doubt the issue is the AIOC itself. More likely a driver or library issue.

Thanks! Helps to know that the problem is not isolated but general. Do you both have M1/M2 Macs by any chance (since you mention arm64 Ubuntu VM). Maybe it could be related? Although I doubt it.

I found this page in the mean time:
https://developer.apple.com/library/archive/technotes/tn2274/_index.html
I should work this through and find any potential problems. Next would be to somehow get myself a macOS VM working. If someone of you has some spare time, could it be possible to record a pcap dump of the USB communications? On Linux I use Wireshark and the usbmon kernel module for that.

I guess the next step to investigate on macOS would be to play+record sound via the AIOC cable with other tools and see if other tools can reproduce it.

Yeah, also a good idea!

EDIT: Can you try setting direwolf ARATE to 24000 instead of 48000? And see what happens.
EDIT2: Also interesting: https://learn.microsoft.com/en-us/answers/questions/103549/usb-audio-2-0-feedback-endpoint-requirements

[skuep]

I have activated CFG_TUD_AUDIO_ENABLE_FEEDBACK_FORMAT_CORRECTION in the tinyusb audio part of the source-code. I remember it saying somewhere in the examples that (although the USB spec says otherwise), USB feedback endpoint format of 16.16 is accepted by most (?) OSes. From the Apple document above however I get the feeling that macOS is very true to the original USB spec (which I applaud). So this might be a problem. With this enabled, it should be more accurate to the spec. But it may have issues with other OSes, which we would need to sort out later.

However can you test this firmware just to check if this is the issue?
aioc-fw-fb10-14.bin.zip

[agrif]

I'm having the same issue with choppy transmit on macOS, and I just tried this firmware and it doesn't seem to help. Reducing the sample rate doesn't help either. One new data point: I'm on an x86-64 mac, not an ARM mac, so that's not the issue at least.

I'm happy to try out any changes you think of. I'll be poking around too, although I don't have much hope since I'm unfamiliar with the systems.

[skuep]

Thanks a bunch for checking the firmware. I assume the regular 1.1.1 firmware has the same issue right? That's probably the one you tried before.

Did you work with direwolf? Can you confirm that the issue is actually the AIOC? Do you have another USB soundcard laying around? Is the stuttering in play and/or recording? Can you use some kind of recording software and just try to record something using the AIOC soundcard?

I am wondering what the issue is. I need to get my hands on a MacOS or maybe try to run it in a libvirt VM under Linux... One thing you could try is recording a wireshark dump of the usb transactions from plugging it in to playing something. But it's kind of advanced unfortunately.

[agrif]

I was using 1.1.0 -- I can upgrade to 1.1.1 and try that, if you think it might make a difference.

Yeah, I was using direwolf. I've used direwolf with a digirig before with no issues. Recording from the AIOC in Audacity appears to work just fine, and I'm decoding packets in direwolf. I don't have an easy way to test playback right now, but I'll dig out an oscilloscope and see what I can do later. I'll also try this in linux, just to confirm that this is macOS only and not some problem with my board in particular. It's only for convenience that I tested it on my mac laptop first!

I've used wireshark before, though not for USB. If I can work out how to do that, I'll post the dump here. Unfortunately I don't know enough about USB for a dump to be any use to me.

[skuep]

The difference between 1.1.0 and 1.1.1 is minor, that should not be it.

The AIOC uses USB Audio Class 2.0, its pretty recent and very common with higher performance external sound units (studio class devices). It's only available since USB 2.0 (although the AIOC is a Full-Speed device and not High-Speed but that should not be important).

I looked around again and found interesting articles like this one. (they refer to USB2.0 but it could very well mean USB Audio Class 2, since USB1.1 devices, i.e. fullspeed only can only use USB Audio Class 1, which is fine).
https://cdm.link/2019/02/apple-2018-glitch/
https://forums.macrumors.com/threads/audio-dropouts-on-big-sur.2271849/page-2
https://discussions.apple.com/thread/252727766?page=2
https://www.reddit.com/r/apple/comments/anvufc/psa_2018_macs_with_t2_chip_unusable_with_external/

Since the problem only seems to be in combination with direwolf. Here someone is reporting the issue where changing the audio library (that the application uses) was changed from SDL to PortAudio. No idea what direwolf uses, but could be a lead also.
UltraStar-Deluxe/USDX#573

What MacOS version do you (all) have? Apparently the problems started with Big Sur (macOS 11.3)
https://www.reddit.com/r/Schiit/comments/n04yiz/dont_update_to_bigsur_113/

If you can get USB capturing with Wireshark to work, you can just send me the pcap file. But at least on Linux you need to load a kernel module for that, not sure if it's even possible on mac.

EDIT: It might be worth opening an issue with direwolf. Seeing if other people with higher performance USB 2.0 audio interfaces on macOS have the same issue as we have with the AIOC.