Conversation
maciejmakowski2003
left a comment
There was a problem hiding this comment.
The current core and native implementation skills structure lacks clear boundaries. I propose a more modular and rigorous split to ensure better maintainability.
- audio-nodes: how to implement c++ audio node, reference to thread safety skill, class hierarchy and characterictics,(possibly audio-param, but not sure about it)
- host-objects: audio-js communication including spsc (and shadow state in future)
- ts-api: how to wrap our c++ and add support for web, web audio api compatibility
- audio-recorder
- native ios- session, player, recorder, interruptions
- native android- FGS, focus(interruptions), , player, recorder
- utils
- thread safety
| - Allocate or free memory (`new`, `delete`, `malloc`, `free`, `std::vector::push_back` that grows, etc.) | ||
| - Acquire any mutex or lock (`std::mutex`, `std::lock_guard`, etc.) | ||
| - Make any blocking syscall (file I/O, socket, `sleep`, `wait`) | ||
| - Call into JavaScript — no JSI calls, no `callInvoker_->invokeSync()` |
There was a problem hiding this comment.
not true
There was a problem hiding this comment.
wwhat is not true here ?
There was a problem hiding this comment.
Invoking event handler from Audio Thread requires callInvoker_->invokeSync().
| ## AudioParam — Automatable Parameters | ||
|
|
||
| Every automatable property (frequency, gain, detune, Q, etc.) is an `AudioParam`. | ||
|
|
||
| ```cpp | ||
| gainParam_ = std::make_shared<AudioParam>( | ||
| defaultValue, | ||
| minValue, | ||
| maxValue, | ||
| context | ||
| ); | ||
| ``` | ||
|
|
There was a problem hiding this comment.
maybe let's split AudioParam from AudioNode skill
| ## Cross-Thread Communication Patterns | ||
|
|
||
| ### JS → Audio (parameter/graph updates) | ||
| Use `CrossThreadEventScheduler` (lock-free SPSC queue). See `utils/CrossThreadEventScheduler.hpp`. | ||
|
|
||
| ### Audio → JS (events like `ended`, `loopEnded`, `positionChanged`) | ||
| Use `IAudioEventHandlerRegistry::invokeHandlerWithEventBody()` which internally calls `callInvoker_->invokeAsync()` — this safely schedules the JS callback on the JS thread from the audio thread. | ||
|
|
||
| ```cpp | ||
| // Audio-thread: fire 'ended' event | ||
| audioEventHandlerRegistry_->invokeHandlerWithEventBody( | ||
| AudioEvent::ENDED, {}); | ||
| ``` | ||
|
|
||
| Callback IDs are stored as `std::atomic<uint64_t>` on the node. `0` means no listener registered. | ||
|
|
There was a problem hiding this comment.
not sure if we want to include that part here.
There was a problem hiding this comment.
I would split it into audio-js communication, audio-nodes, audio recorder and other audio objects(like audio param, context)
Closes #
Introduced changes
Checklist