SDLPerformAudioPassThru in latest build is fairly slow

[kkhemka-amzn]

Bug Report

When using SDLPerformAudioPassThru, the delay between when the request is sent to the head unit and when the app actually starts receiving the audio data is fairly large. On our app running SDL 7.1.1, the delay is usually between 1.4 and 1.6 seconds. When testing the older version which was running 4.7.2, the delay was between 0.9 and 1.2 seconds. I've checked and both apps are not running anything else at the same time the SDLPerformAudioPassThru request is sent.

I also ran this test on Android and our app on Android takes between 1.2 and 1.4 seconds. When Ford learned this, they requested we start this ticket because ~1.5 seconds is far too much for them. Half of the time, the sound being recorded loses so much at the beginning because the jingle is played immediately from the request, but the recording doesn't start till so much later.

We will also be creating a ticket on Android.

Reproduction Steps

1. Send SDLPerformAudioPassThru request to head unit
2. Track time it takes from the time the request is sent to SDL library via sdlManager.send() till when audio data starts coming into the audioDataHandler.

Expected Behavior

Start recording when the jingle is played.

Observed Behavior

Jingle is played and then recording starts ~1.5 seconds after that. Also from using the older SDL libraries, it takes about half a second more than before.

OS & Version Information

• iOS Version: 13.3
• SDL iOS Version: 7.1.1
• Testing Against: Ford+Alexa iOS App, Ford SYNC head units

[joeljfischer]

I did some investigation. There are a number of things to note here:

1. The fact that the jingle is played before audio is being captured is a hardware issue and has nothing to do with this library. The hardware you are using should be playing the jingle when the device is ready to capture audio. I think that this may, in fact be the case, because the division between when recording starts and when data is delivered seems to be muddled in this issue. This is explored in point 2 below.
2. The received audio data is not dependent on when the audio starts being received in the app. The head unit captures audio data and then passes it along to the app in chunks, and when that audio is being delivered to the developer has no impact on when audio starts being recorded. So, even if audio is being received 0.4 seconds later by the app, that does not mean that less audio is being captured, just that it is being delivered to the developer later. The "expected" and "observed" behaviors are therefore incorrect. You state "recording starts ~1.5 seconds after that." This is not true. Recording is based on the hardware. The delivery of the first batch of audio data is 1.5 seconds after the jingle.
3. The delivery delay is also somewhat hardware dependent. When testing with Manticore, I saw a delay of ~1.1 - 1.2 seconds, and that's with delivery of audio data over the internet.

In conclusion, I don't think this is a significant issue that warrants additional investigation. Even though delivery of audio data is delayed compared to v4.7.2 by a few fractions of a second, all the audio data that was being captured before should still be captured.