The audio module (C_MODULE_AUDIO)¶

C_MODULE_AUDIO owns the audio DSP and amplifiers. It carries out source changes that the scheduler decides, holds the AUX input setting, and turns radio events, including AUX signal changes, into DBUS signals. This page covers the 273 functions of the family in the stock NAV SMEG5.43.A.R2 image.

How this was read¶

• Every function was decompiled through the shared Ghidra server; references come from the same bl / lis+addi / data-pointer scan as tools/survey.py (Firmware map).
• 25 functions are read: the AUX path, the lifecycle, the event dispatch and the mute logic were followed by hand. They are listed below.
• 248 are inferred: classified from their names, strings and a machine digest of the decompile (calls, fields, Call_action ids), not read line by line. They are summarised by purpose, not listed one by one.
• The only executed result is the media app's dispatch of 0xcc (below), emulated on the stock image.

What matters for AUX¶

1. The AUX "status" the media app reacts to is a setting, not a signal. Read. There are two AUX quantities:
   • Get_aux_status (0x013b9c8c) returns +0x8c, the stored AUX input setting: the audio/Auxiliary_Status user key, 0..3, set from the media options menu. Confirmed in disassembly: it loads 0x8c(r31) whenever the lifecycle state +0x74 is non-zero, and the only stores to +0x8c in the family that write this object are setAUXGain (0x013bba28) and read_sqlite_AudioUserData (0x013caba8), which loads the key.
   • Get_AUX_signal_status (0x013bc02c) returns signal presence from the radio front-end (C_I2C_SMART_RADIO).
2. Two DBUS signals, and the media app listens to the setting one. Read. AUDIO_AUX_INPUT_STATUS_CHANGED is raised when the setting is written (setAUXGain, and the diagnostic Set_diag_aux). AUDIO_AUX_SIGNAL_STATUS_CHANGED is raised on a signal change. C_BCM_HMI_AUDIO_CLIENT turns the first into HMI message 0xcb and the second into 0xcc (li r4,0xcb at 0x025cdf1c, li r4,0xcc at 0x025cded0). The media app's AUX handler runs on 0xcb. C_HMI_MEDIA_APP_BASE::HandleDBUSMessage has no 0xcc case: its dispatch sends 0xcc to the default branch (executed: the dispatch window emulated on the stock image, tests/test_firmware_nav.py). The audio app uses 0xcc only to refresh its menu (read). So no stock code path activates AUX because a signal appeared.
3. Every successful boot re-announces the setting once. Read. ElabRADIO_READY_FOR_INIT_0 ends with setAUXGain(+0x8c, 1), which raises AUDIO_AUX_INPUT_STATUS_CHANGED. Whether the media app is listening by then is not known.
4. Signal changes before the radio has started are dropped, and AUX is kept muted while it is the current source with no signal: the flag at +0x168, which the vendor's own log text calls AUXSign_mute. RadioMuteManager is its only functional reader, so the mute goes with one instruction — patches/aux-no-idle-mute.json (the AUX idle mute). Read, and the flag's path executed.

What this means for the patches is in The AUX chain and Bearing on the AUX patches below.

The module¶

C_MODULE_AUDIO is a singleton, object id 0x3c28 in C_OBJ_PTR_Table, created by Instance(). It owns the audio DSP and amplifiers, reached through a Radio / C_I2C_SMART_RADIO object.

• It runs its own VxWorks task tAudTask, spawned in Open with Audio_task_handler -> Module_routine.
• The task serialises work through a message queue (+0x64, depth 0x32) and a mutex (+0x68). Read.
• Callers outside the task use two paths:
• the Cmd_*/Get_*/Set_* methods, which take the mutex and run on the caller's thread. Almost all are reached only from C_SRV_AUDIO::bcm_*, the DBUS server, or from VxWorks shell helpers (do*);
• the Elab_event_* posts, for radio, VAN and CAN events.

State fields¶

Events in (subscriptions)¶

All but the first two are subscribed at the top of Module_routine (read). The module also queues its own timer events: mute timers, beep ends, rear volume, amplifier thermal and car speed.

Actions out (Call_action -> C_SRV_AUDIO private message -> DBUS on com.MM.BCM_Audio)¶

Actions 10, 0xd, 0x10-0x12 and 0x16 are not subscribed by SubscribeByAudio. Whether anything else subscribes them is not known.

The AUX path end to end¶

Signal presence (read):
  radio I2C decode -> C_I2C_SMART_RADIO event 0x3d
    -> Audio_event_handler(4) -> Elab_event_AUDIO_AUX_SIGNAL_STATUS_CHANGED (queue 5)
    -> tAudTask: Elab_AUDIO_AUX_SIGNAL_STATUS_CHANGED
         st_audio < 10 -> dropped
         source == AUX -> update +0x168, RadioMuteManager
         Call_action(4) -> msg 5 -> DBUS AUDIO_AUX_SIGNAL_STATUS_CHANGED
    -> C_BCM_AUDIO_CLIENT -> C_BCM_HMI_AUDIO_CLIENT -> HMI message 0xcc
    -> C_HMI_AUDIO_APP_BASE::HandleDBUSMessage: refresh the audio menu if one is on screen
       (C_HMI_MEDIA_APP_BASE::HandleDBUSMessage has no 0xcc case)

AUX input setting (read):
  menu slider (C_HMI_MEDIA_MENU_BT_AUX_Option: 0/1/2 -> status 0/1/3)
    -> C_BCM_HMI_AUDIO_CLIENT::Set_aux_status -> DBUS -> C_SRV_AUDIO::bcm_Set_aux_status
    -> C_MODULE_AUDIO::Set_aux_status -> setAUXGain: radio cmd 0x33, +0x8c = status
    -> Call_action(3) -> msg 4 -> DBUS AUDIO_AUX_INPUT_STATUS_CHANGED
    -> C_BCM_AUDIO_CLIENT (+0x50 listener, Link A) -> C_BCM_HMI_AUDIO_CLIENT -> HMI message 0xcb
    -> C_HMI_MEDIA_APP_BASE::HandleAudioAuxInputStatusChnged
         state = (Get_aux_status != 0); acts only on a change -> ActivateSource(aux, true)
  boot: Open -> readMemFlashInfo -> read_sqlite_AudioUserData loads +0x8c
        ElabRADIO_READY_FOR_INIT_0 -> setAUXGain(+0x8c, 1) -> the same signal, once

Relation to C_MGR_SRC and C_I2C_SMART_RADIO¶

• C_MGR_SRC decides and C_MODULE_AUDIO executes (read).
• The HMI source objects (C_HMI_SrcAudio::SourceStart, SourcePauseEnd, the TA, nav and BT sources) call C_BCM_HMI_AUDIO_CLIENT::Cmd_change_source(slot, param) over DBUS.
• C_SRV_AUDIO::bcm_Cmd_change_source looks the slot up in its table (this + slot*0x1c + 0x80..0x90: MGR source id, audio source type, two flags, parameters) and calls C_MODULE_AUDIO::Cmd_change_source.
• The module never calls C_MGR_SRC. How the slot table is filled (presumably AllocateSource) was not read.
• C_I2C_SMART_RADIO carries every DSP command. SendCmdRadio is the single choke point (2 070 instructions), and command 0x33 carries the AUX input selection, not a level (see the level trim below). It is also the source of all radio events, including AUX signal 0x3d. The module reads signal presence only through Radio::Get_AUX_signal_status (0x0131ae40) -> C_I2C_SMART_RADIO::Get_AUX_signal_status.

The per-source level trim — where the AUX gain is¶

Issue #8 asks for the default AUX gain. There is no single "AUX gain" knob: the module has two unrelated mechanisms, and only one of them is a level.

Input selection. C_MODULE_AUDIO::setAUXGain(TYPE_AUDIO_AUX_STATUS, bool) (0x013bb7ec) maps the saved AUX setting (0..3) to a radio command — SendCmdRadio(TYPE_COMMAND, 0x33, {u16 1, u16 <sel>}) — with one branch per setting. That chooses which AUX input the front end listens to. It sets no level. (read)

Level. The level is a per-source trim held in the audio-parameters object. C_RI_AUDIO_PARAMETERS_CLASS keeps five floats per AUDIO_SOURCES_TYPES, and GetSourceScalers(t, float&) (0x0133b668) reads one of them at:

object + 0x348 + 4 * (5*t + K)          K = the u8 at +0x260 (4 on this image)

so a source's group starts at 0x358 + 20*t and the slot GetSourceScalers returns is 5t + 4 — for AUX (AUDIO_SOURCES_TYPES 5) that is object + 0x3bc. (read)

InitSourceScalers_in_dB() (0x01334764) -> C_RI_AUDIO_PARAMETERS_CLASS::InitSourceScalers (0x0133a390) fills it from .rodata floats. Which set of floats is used is chosen by a project-label jump table at 0x02F445E8 (16 entries, indexed by the label). (read)

On the NAV 5.43.A.R2 image the label global at 0x035DA760 reads 1, selecting the block at 0x0133a3cc. For AUX that block writes +0x3bc..+0x3cc; the slot GetSourceScalers returns (+0x3bc) comes from the float at 0x03071C34 = −13.95 dB. The neighbours are −11.48 and +4.12. (read from the image — this is static, not emulated.)

So the AUX input is trimmed roughly 14 dB below full scale by default, which is the number issue #8 is looking for and is consistent with a piggyback landing quiet.

Bearing on the AUX patches¶

Everything in this section is inferred from the reading above.

• A true "switch when a signal appears" needs a new wire. Stock routes signal changes only to a menu refresh. A patch would have to do two things:
• deliver 0xcc to the media app's AUX handler;
• make that handler test Get_AUX_signal_status, not Get_aux_status.

Two constraints apply: - the signal event is dropped before st_audio = 10; - AUX is muted while silent (+0x168).

Both matter if AUX is selected with no signal.

Both changes are patches/aux-signal-switch.json: executed under emulation, not flashed; see The AUX signal path. A detection before st_audio = 10 is still lost, and aux-sticky is paired with it so silence does not release AUX. - Dropping the idle mute is independent of all of that. +0x168 has exactly one reader that acts on it, RadioMuteManager, so patches/aux-no-idle-mute.json removes the mute with one nop and touches no signal routing and no source switching (the AUX idle mute). Inferred from the reading, and the resulting mute decision executed. - Boot to AUX. The boot-time AUDIO_AUX_INPUT_STATUS_CHANGED from ElabRADIO_READY_FOR_INIT_0 means HandleAudioAuxInputStatusChnged may also run at boot. aux-boot-restore clears PrOnly both there (0x02303474) and in InitApp (0x022c0678). The request the boot restore sees comes from InitApp: clearing it there is what made AUX match, and the pair with aux-boot-default boots to AUX on the car (executed; Verification).

Functions read closely¶

Addresses are symbol starts in NAV 5.43.A.R2.

The rest, by purpose¶

The remaining 248 functions were classified, not read. Tier: inferred for every row.

Not known¶

• Which radio I2C message sets event 0x3d, and its debounce (DecodeMsgXXX), belongs to the C_I2C_SMART_RADIO reading.
• Whether the HMI listener (C_BCM_AUDIO_CLIENT+0x50, Link A) exists when ElabRADIO_READY_FOR_INIT_0 announces the AUX setting at boot. This needs a spy trace with DBUS logging, or emulation of the HMI start-up order.
• The meaning of TYPE_AUDIO_AUX_STATUS values 1 and 3 in the vendor UI; the menu offers three positions, mapped to 0/⅓.
• Callers of Set_diag_aux, Get_diag_aux and the other *_diag_* setters with "(none found)". They are probably reached through a diagnostic table this scan does not model.