USB Audio: libusb iso OUT for TX (companion to #83)

[patrickrb]

Summary

Follow-up to #83. That PR fixed the input path on the car-dash; this one fixes the output path the same way. The first end-to-end QSO test on the car-dash caught the symmetric bug — (USB direct) selected for Audio Output causes TX to abort after ~286ms because UsbAudioDevice.writeAudio() calls UsbRequest.initialize() on the OUT endpoint, the car-dash kernel returns false (same iso-not-supported behavior as input), writeAudio returns immediately, FT8TransmitSignal.playViaUsbAudio short-circuits to afterPlayAudio(), and the PTT releases before any audio is sent.

What this gives you

With both #83 (RX) and this PR (TX) shipped, (USB direct) selected for both Audio Input and Audio Output, the FT8 audio pipeline becomes completely independent of Android's audio framework:

• TX audio goes straight to the radio's USB iso OUT endpoint via libusb / USBFS.
• No AudioTrack session is opened, so Android's audio policy never tries to route TX audio anywhere.
• Spotify / YouTube / Maps / Android Auto can keep playing through the car speakers uninterrupted while FT8 transmits — no ducking, no fight for the speaker, no rerouting.
• Same for the input side via USB Audio: libusb-backed iso capture (fixes car-dash) #83: media output and FT8 capture are two independent pipelines.

What's in it

• usb_audio_capture.cpp: new OutputSession + onOutputComplete callback. Same N=4 transfers × 8 packets pattern as the capture side. The caller blocks on libusb_handle_events_timeout_completed until the in-flight counter drops to zero. Errors propagate back as libusb error codes.
• UsbAudioNative.nativeWrite(): synchronous JNI entry point. Takes the fd + endpoint params + pre-formatted PCM byte buffer (Java still does float→int16 + channel duplication, same as before) and returns 0 on success or a negative LIBUSB_ERROR_* on failure.
• UsbAudioDevice.writeAudio(): try the libusb path first, fall back to the original UsbRequest loop on non-zero return. Both paths log to debug.log so the next car-dash run will tell us exactly which one took the TX.

Test plan

• assembleDebug compiles cleanly across all four ABIs. JNI symbol Java_com_bg7yoz_ft8cn_wave_UsbAudioNative_nativeWrite is present in libft8af_usb.so.
• Pixel 8 smoke test before merge (not yet run — Pixel was unplugged when I tried installDebug after pushing). Need to confirm the existing UsbRequest output path doesn't regress on devices where it was already working, AND that the libusb path can drive an iso OUT endpoint on the Pixel.
• Car-dash via Play internal track after merge: set Audio Output to (USB direct), run a full TX cycle. Expected lines in debug.log:

  serial.send[4]: MX1;
  UsbAudioDevice: trying libusb native write fd=... ep=0x... bytes=...
  nativeWrite: 4 transfers submitted, pcmLen=... ep=0x... maxPkt=...
  UsbAudioDevice: libusb native write OK
  serial.send[4]: MX0;       ← ~12.6s after MX1, not 286ms
  

• A/B test on car-dash: with (USB direct) selected for output, start Spotify or another music app. Confirm music keeps playing through car speakers while FT8 TX uses the USB radio. This is the user-visible benefit, not just absence of bugs.

🤖 Generated with Claude Code