Adjust WiFi settings and audio pipeline timings

[gnumpi]

This PR enhances the robustness of the audio pipeline, specifically targeting scenarios with weak Wi-Fi connections. The changes aim to improve reliability, minimize interruptions, and maintain smooth audio streaming even under challenging network conditions.

[that1guy]

Sorry I don't have helpful test results to offer here - my wifi is stable across all 4 access points therefore all my Sat1's appear to behave the same as before (neither better or worse).

I've tested:

• network latency over time before and after firmware update
• packet loss before and after firmware update
• music streaming
• Wake word responsiveness
• Voice pipeline response time

I recommend we get @ms1design feedback during his workday tomorrow. His wifi may be a better baseline than my environment.

Thanks @gnumpi

[ms1design]

TLDR (my environment)

• min -65 dBm to work without issues
• beware of any WiFi signal shielding from other home appliances!
• power_save_mode: none for wifi component could improve the connection stability a bit in worse conditions while not streaming. Dunno if we can enable this as we don't plan to power the Sat1 from battery?
• CORE rotation relative to the access point affects the WiFi signal by 5 dBm to 10 dBm

Results

Here are my results. Without dedicated access point for Sat1 my baseline WiFi signal strength with the HAT and CORE connected varies depending if any obstacles could shield the WiFi signal, I tested in two environments:

Testing environment (at my desk)

• 5.5m to access point with -80 dBm
• shielded by 27" LCD panel in between of Sat1 and access point
• WiFi signal monitoring interval: 60s
• Music Assistant 2.3.6 streaming FLAC

desk_wifi_signal_chart_history.csv

1. develop branch

1000 packets transmitted, 989 packets received, 1.1% packet loss
round-trip min/avg/max/stddev = 5.747/205.122/1598.791/218.570 ms

Preview
https://drive.google.com/file/d/1SmJWX7a-6vZaTjNVccuQfD1PpTyMFljX/view?usp=drive_link

Observations

• The audio stuttering a lot and is not usable for streaming music from Music Assistant;
• Sat1 recognises the Wake Word correctly, but struggles with streaming the recorded audio to HA and/or fails with receiving the audio response from HA which finally causes dropping WiFi connection (red arrows on above chart).

2. wifi_and_audio_pipeline_adjustements branch

1000 packets transmitted, 993 packets received, 0.7% packet loss
round-trip min/avg/max/stddev = 6.788/933.435/5566.679/744.194 ms

Preview
https://drive.google.com/file/d/1ofA8ftahrYxf1LQhXCAdid99yQw-3Mj7/view?usp=drive_link

Observations

• The audio stuttering slightly less that with develop, but still breaks all the time. Seems like -80 dBm is too weak.
• Sat1 recognises the Wake Word correctly, but struggles with streaming the recorded audio to HA and/or fails with receiving the audio response from HA which finally causes dropping WiFi connection (red arrows on above chart).

Testing environment (kitchen corner)

• 5.5m to access point with -70 dBm
• not shielded by anything
• WiFi signal monitoring interval: 60s
• Music Assistant 2.3.6 streaming FLAC

kitchen_wifi_signal_chart_history.csv

1. develop branch

1000 packets transmitted, 999 packets received, 0.1% packet loss
round-trip min/avg/max/stddev = 5.481/105.525/1557.919/167.120 ms

Preview
https://drive.google.com/file/d/1a93xTr7RjEGTWk-5N49Fc_UDu7kNvzW1/view?usp=drive_link

Observations

• The audio stuttering a bit, overall it's listenable;
• Sat1 recognises the Wake Word correctly, streams the recorded commands and responses from HA correctly; Sometimes (second take) it might stuttering a bit;
• No connection drops;

2. wifi_and_audio_pipeline_adjustements branch

1000 packets transmitted, 999 packets received, 0.1% packet loss
round-trip min/avg/max/stddev = 5.486/366.529/4810.797/422.598 ms

Preview
https://drive.google.com/file/d/1uLoVP2GE2h_khbMtYa1Z412Tr4BwkDqA/view?usp=drive_link

Observations

• The audio stuttering just a bit, overall it's listenable;
• Sat1 recognises the Wake Word correctly, streams the recorded commands and responses from HA correctly; Sometimes (second take) it might stuttering a bit;
• No connection drops;

Ideal environment (without stuttering while streaming)

• 3m to access point with -65 dBm
• not shielded by anything
• WiFi signal monitoring interval: 60s
• Music Assistant 2.3.6 streaming FLAC

1. develop branch

1000 packets transmitted, 1000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.671/80.764/3077.654/174.163 ms

2. wifi_and_audio_pipeline_adjustements branch

1000 packets transmitted, 999 packets received, 0.1% packet loss
round-trip min/avg/max/stddev = 5.064/232.258/1801.348/252.483 ms

General observations

• in my environment from testing with PowerBank as a power source it looks like the -65 dBm is the lowest value for music stream not to stutter and for WakeWord detection and commands streaming correctly;
• seems like the CORE rotation affects the WiFi signal - it's working better if CORE board is on top or at least facing the access point with Southern edge.
• when placed in different room (6m to access point, 1 thin plaster wall) its not usable without access point in that room;
• having the power_save_mode: none for wifi is making the WiFi signal more stable when <-70 dBm:
  
• User could not be aware that certain devices like a big LCD Panels between Sat1 and Access Point could shield the WiFi signal (just like in my case);
• Music streaming from MA works better if we turn the Sat1 upside down - to have WiFi antenna on top, but the Mics don't pick the WakeWord: https://drive.google.com/file/d/1NALBrjvlg-irjn-c47yWL1EAOfRjo_jE/view?usp=drive_link

[that1guy]

Thanks for all thorough details here @ms1design! That video and the music streaming stuttering is pretty painful to see/hear though. By any chance do other ESP32 (s3 or not) get the same quality wifi signal on that counter?

I think we should merge this code as it doesn't seem it's doing harm.

[that1guy]

Testing reveals that this may help wifi under certain but not all conditions. merging.