[Yealink]Inquiry regarding ASHA packet loss, Bluetooth stress test disconnection, Dear Nasser Fathi and the NXP Support Team,
Thank you for your previous recommendation to address the NXH2004 ASHA DSP out-of-sync issue using the following APIs and event:
AUDIO_ConfigureLlSyncParams()
kAUDIO_Event_LlOutOfSync
AUDIO_ForceSharedBufResync()
During ASHA playback and reconnection testing, we observed recurring out-of-sync events after resync calls returned kStatus_Success. We also observed periods in which valid encoded audio continued to be written to the shared buffer, but currentBufferRowNumber and nextExpectedTimestamp, obtained through AUDIO_GetDspSharedBufInfo(), remained unchanged between samples approximately five seconds apart.
Our project is currently limited to SDK 6.2. For the previously reported persistent-silence issue, we would appreciate clarification of the recommended recovery procedure and expected outcome using SDK 6.2.
1. Expected recovery outcome and confirmation of success
Once the radio link has stabilized and valid audio data and timestamps resume, is your recommended procedure expected to restore sustained normal audio playback without resetting NXH2004 or intentionally disconnecting BLE?
When AUDIO_ForceSharedBufResync() returns kStatus_Success, does this mean that the DSP command has completed successfully, or that the DSP has actually regained synchronization?
Please clarify:
Is there a synchronization-recovered event or an API for querying the synchronization state?
Is the absence of further out-of-sync events, or renewed progression of the DSP row and expected timestamp, sufficient to confirm successful recovery?
What observation period is recommended for verifying recovery? After valid input resumes, how long should synchronization and normal playback take to recover?
Which failure conditions can be recovered without a device reset, and which require a different recovery procedure?
2. Recommended recovery procedure and handling of repeated events
Please confirm the recommended handling of the two out-of-sync causes:
For kAUDIO_LlOutOfSync_Sync_Lost_During_Playback, should the application invoke resync immediately or first wait for the radio link to stabilize? What SDK information should be used to determine that the link has stabilized?
For kAUDIO_LlOutOfSync_Sync_Not_Achieved_At_Start, UM11981 §4.4.3 recommends stopping and restarting the audio chain. Is AUDIO_StopChains() followed by AUDIO_StartChains() sufficient, or must the chain be released and reconfigured, including reapplication of QoS or LL synchronization parameters?
Please specify how the shared FIFO, application buffers, and timestamp state should be handled, together with the recommended settling time, retry interval, and retry limit.
We have observed Sync_Not_Achieved_At_Start both after resync, before any chain restart had been performed, and after chain restarts while the application-level ASHA session remained active. Could you explain the DSP state transitions associated with these two cases?
If further out-of-sync events arrive after a recovery command returns success, how should the application distinguish between:
A new synchronization failure;
An ongoing synchronization attempt that has not yet completed;
A delayed event from an earlier failure?
May these recovery APIs be called directly from the audio event callback, or should they be deferred to a task? Please also clarify any serialization requirements for audio API calls.
3. Detection and recovery when DSP processing does not advance
You previously noted that not all mute conditions generate kAUDIO_Event_LlOutOfSync.
When valid encoded audio continues to be written, but the DSP row and expected timestamp do not advance, what SDK-supported method do you recommend for distinguishing stopped consumption from a normal synchronization-wait condition?
We also observed that the missing-packet indication counts accumulated over an observation interval could be zero while the DSP information remained unchanged. Can a zero missing-packet count be used as evidence of normal decoding? Under what conditions do missing-packet or out-of-sync indications cease?
If shared-buffer resync cannot resolve this condition, please provide the recommended recovery method.
For an unresponsive DSP, are shared-buffer reads and synchronous recovery commands guaranteed to return within a bounded time? What timeout and error-handling procedure do you recommend?
After receiving kAUDIO_Event_WatchdogIndication, is it supported to continue calling audio APIs to attempt local recovery, or must a specific reset procedure be followed?
the history of the mail can be found in attached file NXH2004 NXH2004SDK @Nasser_F could you please have a look, Thanks! Re: [Yealink]Inquiry regarding ASHA packet loss, Bluetooth stress test disconnection, i cannot attach the file, just paste here your last response before the issue
Hi 饶舜驰, Answer 1: Yes, there is a feasible solution to resolve the DSP out-of-sync issue without restarting the NXH2004. We have introduced the following APIs and event:
AUDIO_ConfigureLlSyncParams()
AUDIO_ForceSharedBufResync()
Event: kAUDIO_Event_LlOutOfSync
To resolve the DSP out-of-sync issue using these new APIs, follow these steps:
Configure the synchronization timeout using AUDIO_ConfigureLlSyncParams().
Monitor for the kAUDIO_Event_LlOutOfSync event.
The DSP generates kAUDIO_Event_LlOutOfSync when it does not receive a valid timestamp for a continuous period longer than the timeout configured through AUDIO_ConfigureLlSyncParams().
Note that not all mute conditions trigger kAUDIO_Event_LlOutOfSync; only those that exceed the configured timeout value will do so.
Upon receiving kAUDIO_Event_LlOutOfSync, call AUDIO_ForceSharedBufResync().
Answer 2: We are not aware of any issue in SDK 6.2 where a disconnection event is missed. Could you provide more details on how you observed this issue? Do you see any error messages in the logs from the failing earbud, such as a hard fault event? If it is possible to reproduce the issue, could you capture an air trace with the PA/LNA signals also connected to the GPIO input of the air tracer? I am interested in determining whether there is any activity on the PA/LNA signals after the issue has been reproduced. Answer 3: When you say "some devices," do you mean that certain phone models cause a memory leak in the application while others do not? If so:
Which device(s) are exhibiting the issue?
Can you confirm whether the issue can also be reproduced using a clean example application from the SDK? Kind regards, Nasser
View full article
