RDKEMW-14903: MFV Device Support in Control Manager

[msmith113]

https://ccp.sys.comcast.net/browse/RDKEMW-14903

[rdkcmf-jenkins]

b'## WARNING: A Blackduck scan failure has been waived

A prior failure has been upvoted

• Upvote reason: ok

• Commit: c469913
  '

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 20 out of 20 changed files in this pull request and generated 6 comments.

[Copilot]

Pull request overview

Copilot reviewed 20 out of 20 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 20 out of 20 changed files in this pull request and generated 5 comments.

[Copilot]

Pull request overview

Copilot reviewed 20 out of 20 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

src/ble/ctrlm_ble_controller.cpp:491

• get_mid_field_voice_capable() always returns true, ignoring the mid_field_voice_capable_ state set by set_mid_field_voice_capable(). This makes the capability flag meaningless and will misreport MFV support.

bool ctrlm_obj_controller_ble_t::get_mid_field_voice_capable() const {
   return true;
}

src/ble/ctrlm_ble_network.cpp:550

• The comment says MFV wake-word sessions use FF, but the code (and the rest of this PR) uses CTRLM_VOICE_DEVICE_MFV. This mismatch is confusing when debugging session source selection.

         // BLE RCUs use PTT for keypress-triggered sessions and FF for MFV wake-word sessions.
         // The voice_device field of the message is set by the caller; it defaults to
         // CTRLM_VOICE_DEVICE_PTT (0) when the struct is zeroed via memset.
         ctrlm_voice_device_t device = dqm->voice_device;

src/ble/ctrlm_ble_network.cpp:2088

• These schedule_status_* calls were commented out rather than being removed or controlled via a flag, leaving dead/commented code in the event handler. If wakeup config/custom list changes should no longer trigger status print/event, consider deleting these lines and adding a short rationale (or gate via a config/verbosity knob). If they should still trigger, uncomment them.

                  controller->setWakeupConfig(dqm->rcu_data.wakeup_config);
                  XLOGD_INFO("Controller <%s> notified wakeup config = <%s>", controller->ieee_address_get().to_string().c_str(), ctrlm_rcu_wakeup_config_str(controller->get_wakeup_config()));
                  //schedule_status_print();
                  //schedule_status_event();
                  break;
               case CTRLM_HAL_BLE_PROPERTY_WAKEUP_CUSTOM_LIST:
                  controller->setWakeupCustomList(dqm->rcu_data.wakeup_custom_list, dqm->rcu_data.wakeup_custom_list_size);
                  XLOGD_INFO("Controller <%s> notified wakeup custom list = <%s>", controller->ieee_address_get().to_string().c_str(), controller->wakeupCustomListToString().c_str());
                  //schedule_status_print();
                  //schedule_status_event();

[Copilot]

Pull request overview

Copilot reviewed 19 out of 19 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (3)

src/ble/ctrlm_ble_network.cpp:2124

• The wakeup-config status update no longer schedules the status print/event because these calls were commented out. This looks like an accidental regression (UI/telemetry won’t reflect updated wakeup config).

                  //schedule_status_print();
                  //schedule_status_event();

src/ble/ctrlm_ble_network.cpp:2130

• The wakeup-custom-list status update no longer schedules the status print/event because these calls were commented out. This looks like an accidental regression (UI/telemetry won’t reflect updated wakeup custom list).

                  //schedule_status_print();
                  //schedule_status_event();

src/ble/ctrlm_ble_network.cpp:557

• The comment says MFV wake-word sessions use FF, but the code now uses the dedicated CTRLM_VOICE_DEVICE_MFV device type. This mismatch makes it harder to reason about routing behavior for BLE voice sessions.

         // BLE RCUs use PTT for keypress-triggered sessions and FF for MFV wake-word sessions.
         // The voice_device field of the message is set by the caller; it defaults to
         // CTRLM_VOICE_DEVICE_PTT (0) when the struct is zeroed via memset.

[Copilot]

Pull request overview

Copilot reviewed 19 out of 19 changed files in this pull request and generated no new comments.

Suppressed comments (7)

src/ble/ctrlm_ble_network.cpp:652

• MFV detection timeout tracking uses a single global ieee address (mfv_detection_pending_ieee) and a single global timer tag. If two MFV wake-word sessions become pending close together (different controllers or repeated detections), the global ieee can be overwritten and the timeout handler may release the wrong controller/session (or fail to release the original).

   unsigned long long ieee_address = g_ctrlm_ble_network.mfv_detection_pending_ieee;
   ctrlm_controller_id_t controller_id;

src/ble/ctrlm_ble_network.cpp:2124

• These calls were previously active and are now commented out, which prevents wakeup-config changes from scheduling the usual status print/event updates.

                  //schedule_status_print();
                  //schedule_status_event();

src/ble/ctrlm_ble_network.cpp:2130

• These calls were previously active and are now commented out, which prevents wakeup custom-list changes from scheduling the usual status print/event updates.

                  //schedule_status_print();
                  //schedule_status_event();

src/ble/ctrlm_ble_network.cpp:557

• Comment says MFV wake-word sessions use the FF device type, but the MFV path sets msg.voice_device = CTRLM_VOICE_DEVICE_MFV. This mismatch is misleading when debugging/maintaining the session-begin flow.

         // BLE RCUs use PTT for keypress-triggered sessions and FF for MFV wake-word sessions.
         // The voice_device field of the message is set by the caller; it defaults to
         // CTRLM_VOICE_DEVICE_PTT (0) when the struct is zeroed via memset.

src/ble/ctrlm_ble_controller.h:165

• This comment references ctrlm_obj_network_ble_t::req_process_detection_voice_session_begin(), but no such method exists (the MFV flow is handled in ind_process_rcu_status() / req_process_voice_session_begin()). The incorrect reference makes it harder to locate the implementation.

   // MFV wake-word (detection-triggered) session state.  Such a session starts audio streaming, waits
   // for the detection data (wake word timing/confidence), then opens the voice session.  See
   // ctrlm_obj_network_ble_t::req_process_detection_voice_session_begin().
   void                             setMfvDetectionPending(bool pending, int audio_fd = -1);

src/voice/ctrlm_voice_obj_generic.cpp:175

• voice_sdk_update_routes() now unconditionally overrides configured/RFC voice server URLs with a hard-coded QA endpoint. This changes production behavior (routing, environment selection, failover) and makes the effective server destination opaque to configuration management.

    static const char *CTRLM_VOICE_HARDCODED_URL = "vrngs://voice-np-eks-ue2i.vrexcore.net/qa20/vrex/speech";
    this->prefs.server_url_src_ptt     = CTRLM_VOICE_HARDCODED_URL;
    this->prefs.server_url_src_ff      = CTRLM_VOICE_HARDCODED_URL;
    this->prefs.server_url_src_mic_tap = CTRLM_VOICE_HARDCODED_URL;

src/ble/ctrlm_ble_network.cpp:2178

• The MFV detection handler starts the “detection data timeout” flow regardless of whether the voice session actually started successfully. If req_process_voice_session_begin fails (e.g., cannot acquire session / audio fd), the controller stays marked MFV-detection-pending and a timer is still started, which can later call voice_session_stream_params_update() for a session that never existed.

                     req_process_voice_session_begin(&msg, sizeof(msg));

                     g_ctrlm_ble_network.mfv_detection_pending_ieee = dqm->rcu_data.ieee_address;
                     ctrlm_timeout_destroy(&g_ctrlm_ble_network.mfv_detection_timer_tag);
                     g_ctrlm_ble_network.mfv_detection_timer_tag = ctrlm_timeout_create(CTRLM_BLE_MFV_DETECTION_DATA_TIMEOUT, ctrlm_ble_mfv_detection_timer_cb, &id_);