Email a short description of the issue and the outcome you want. We'll discuss expectations, scope, constraints, then decide the next step and make a plan.

Services · Android audio

Need help with your Android audio?

Q: What should I include in the first message?

Share what's happening vs expected, target devices or Android versions, how often it occurs, and any constraints like deadlines or NDA requirements.

Q: Do I need a minimal repro or test build?

Not to start. We begin with triage and scope, and only request a test build or logs if reproducing the issue is necessary.

Q: Do you sign NDAs?

Yes, I'm happy to work under a mutual NDA before reviewing builds or source.

Q: Hourly or fixed price?

Investigation and triage are usually hourly; once scope is clear we can switch to fixed-price milestones.

Android audio engineering support

We help teams and independent developers build, debug, and optimize real-time audio on Android—so you get stable low latency, fewer glitches, and DSP features that ship reliably across devices.

8+ years experience

Real-time audio / DSP

Native audio

C++/NDK • Oboe/AAudio

Collaboration

Clear, regular updates

Let’s get started

Service options

How we can help

Choose an engagement type. Each can be short, focused, and shipped with a clear handoff.

Low-latency audio engine foundation (new build)

Oboe/AAudio stream setup + safe start/stop lifecycle
Real-time callback architecture (no locks/allocations)
Minimal test UI + logs/trace markers for validation

Glitch/crash/ANR debugging for audio apps

Reproduction plan + targeted logs
Perfetto/systrace + timing evidence
Fix + verification checklist + test build

DSP optimization (CPU/battery, NEON where relevant)

Hotspot profiling + per-block timing
Reduce CPU spikes at low latency
Vectorization/NEON where it pays off

Release support for NDK audio apps (Play Console / regressions)

Native crash triage (tombstones, symbols, stack traces)
Regression checks across devices/Android versions
PR + notes + reproducible build for rollout

Routing & Bluetooth reliability (focus, device changes, resume)

Audio focus + route change handling (BT/wired/speaker)
Consistent behavior on pause/resume and interruptions
Route-aware re-init strategy with guardrails

iOS → Android audio porting

Port audio engine concepts to C++/NDK + Oboe/AAudio
Match timing/latency “feel” and lifecycle behavior
Feature parity validation + Android-specific fixes

Let’s get started

Not sure which option fits? Start with the symptoms below.

Common audio problems

Pick the symptom you’re seeing. The panel on the right shows the likely causes and diagnosis chain instantly.

Clicks & pops

Small glitches when starting/stopping, changing settings, or hitting certain notes.

Likely causes: State transitions Timing & buffering

Crackling / static

Harsh noise under load, especially on some devices or at low latency.

Likely causes: Timing & buffering CPU / DSP load Device variability

Stuttering & gaps

Audio drops out briefly, repeats, or “skips” during playback.

Likely causes: Timing & buffering CPU / DSP load Routing & focus

Slow / delayed response

Controls feel laggy; sound reacts late to taps, keys, or MIDI.

Likely causes: Timing & buffering CPU / DSP load Routing & focus

Out of sync / drift over time

Loops slowly desync; long sessions don’t stay locked.

Likely causes: Timing & buffering Device variability

Works on some phones, breaks on others

Same build, different behavior across devices or Android versions.

Likely causes: Device variability Timing & buffering Routing & focus

Effects feel heavy / CPU spikes

DSP features cause glitches, battery drain, or can’t run at low latency.

Likely causes: CPU / DSP load Timing & buffering

Switching between sources isn’t smooth

Plugging headphones, Bluetooth changes, calls/notifications, or app resume causes hiccups or changes.

Likely causes: Routing & focus State transitions

No sound / no recording

Signal path goes silent, audio input isn’t captured, or meters stay flat even though the app is running.

Likely causes: Routing & focus State transitions Device variability

What it looks like: crackling, stutters, random glitches under load, unstable latency.
How we confirm: underrun stats + callback timing + thread scheduling traces.
Typical fixes: tune stream/buffer sizes, stabilize callback scheduling, reduce contention.

What it looks like: glitches on calls/notifications, background/foreground changes, BT/wired switching.
How we confirm: route/focus event logs + device repro + trace around transitions.
Typical fixes: consistent focus handling, route-aware reconfig, safe stream rebuild strategy.

What it looks like: clicks at start/stop, “works until resume”, sporadic bugs during switching.
How we confirm: state timeline + ordering checks + race/edge-case reproduction.
Typical fixes: tighten state machine, avoid double-start/stop, reset/re-init correctness, safe handoffs.

What it looks like: glitches when enabling effects/analyzers, battery spikes, can’t hold low latency.
How we confirm: CPU hotspots + per-block timing + trace markers around DSP stages.
Typical fixes: optimize hot paths, reduce allocations, simplify algorithms, move work off the audio thread.

What it looks like: one device is fine, another cracks/stutters, or latency is wildly different.
How we confirm: small device matrix + controlled settings + traces to isolate vendor behavior.
Typical fixes: device-aware defaults, fallback configs, guardrails for fragile routes/buffer limits.

Process

Process + deliverables

Bring the symptom. We reproduce it, prove the cause with traces, implement fixes, and ship testable builds.

Diagnose & reproduce

If needed: test build / targeted repro + devices
Symptom profile + log conditions

Measure & prove

Perfetto/systrace + structured logs
Timing markers + before/after comparison

Fix & validate

Stream/state/routing + DSP changes
Validated on the agreed device range

Ship & hand off

Patch/PR with clear notes
Test builds (A/B toggle optional)

Deliverables

Evidence + code + a build your team can test.

Diagnosis summary
Trace pack (Perfetto/systrace + logs)
Patch/PR (C++/NDK + Kotlin/Java if needed)
Test builds (APK/AAB/module)
Verification checklist

Let’s get started

Short engagements welcome. Clear updates, reproducible results.

Client apps on Google Play

Selected client work

Shipped under iDance International Limited (client-owned listings).

KeyCanvas — physical keyboard companion app

Work delivered: UI updates + replacement audio engine for a physical keyboard accessory (Bluetooth HID) with a low-latency core.

Features

Connectivity: Wireless Bluetooth HID support for iDance keyboards
Tone generator: Tone engine with 100 tones
Styles: 200 styles (rhythms / backing tracks)
Effects: Performance-focused tone effects
Looper / Sequencer: Simple loop sequencer for short patterns

Tech: Android · C++ · Oboe/AAudio · Bluetooth HID · Java/Kotlin · Jetpack Compose

SuperRocker — physical drumkit companion app

Work delivered: Android implementation for an integrated companion app for a physical drumkit, using a low-latency Oboe audio engine + Bluetooth connectivity focused on responsive play. Conversion of an iOS app.

Features (Play Store)

4 on-screen drum pads
8 drum kits / 32 sounds
21 backing tracks + 21 interactive backing tracks (tempo adjustable)
Effects: Reverb · Distortion · Flanger (adjustable)
Connectivity: iDance controller support (iROCKER STAGE)
Looper: Record rhythms and add layers

Tech: Android · C++ · Oboe/AAudio · Bluetooth · Java/Kotlin · Jetpack Compose

Note: Screenshots/branding belong to the client; links provided for reference.

FAQ

How do we start?

Email a short description of the issue and what outcome you want. We’ll discuss expectations, scope, and constraints, then decide the next step and make a plan.

What should I include in the first message?

Just the basics: what’s happening vs expected, target devices/Android versions, frequency, and any constraints (deadline, NDA, limited access, etc.).

Do I need a minimal repro or test build?

Not to start. We begin with triage and scope. If a reproduction build is needed, I’ll request it (along with logs/traces) as a next step.

Do you sign NDAs?

Yes—happy to work under a mutual NDA before reviewing builds or source.

Hourly or fixed price?

Investigation/triage is usually hourly; once scope is clear we can switch to fixed-price milestones.

Response time / start date?

I reply within two business days. Start dates depend on availability—flag urgent issues in the subject.

Contact

Let’s get started

Email projects@cc-rom.com with a short description of the issue and the outcome you want. We’ll discuss scope, expectations, and the best next step.

Helpful if you have (optional):

Devices / Android versions (even partial)
Steps to reproduce or when it usually shows up
Logs, traces, or a quick screen recording