app: prj.conf: use trigger threshold of 1 as default

[kv2019i]

Set CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD=1 as the default behaviour.

Given most actions in the DSP FW happen every LL (msec) tick, having defer logic of upto 100msec in the logging subsystem is not really helpful. Logging thread should be preempted by higher priority threads in any case.

This setting will cause the logger thread to be woken up (with a semaphore) every time a log entry is printed and no timer is used at all. The actual logging will not happen until logger thread gets to run, but the wakeup request is immediate.

This setting works better with logging backends that have a limited internal buffer (like mtrace and Zephyr winconsole) that are commonly used with SOF targets.

[kv2019i]

FYI @checkupup this might help to avoid dropped messages as well. Got the idea to revisit this setting in our default prj.conf while reviewing your zephyrproject-rtos/zephyr#105550 .

If you have a piece of code (like a module init sequence) emitting a lot of logs, this can easily overwhelm backends like mtrace and winconsole where the backend has a limited buffer and the host may sleep for relative long periods of time (in terms of DSP time) between emptying the buffer. @checkupup additional buffer will help, and this PR should also show a benefit. Neither will help if DSP is continuously sending more logs than the log transport can handle, but for those case, move to DMA based logging (with probes) is the right solution.

Note: keeping as draft to get some CI feedback on this before marking ready for review.

[checkupup]

FYI @checkupup this might help to avoid dropped messages as well. Got the idea to revisit this setting in our default prj.conf while reviewing your zephyrproject-rtos/zephyr#105550 .

If you have a piece of code (like a module init sequence) emitting a lot of logs, this can easily overwhelm backends like mtrace and winconsole where the backend has a limited buffer and the host may sleep for relative long periods of time (in terms of DSP time) between emptying the buffer. @checkupup additional buffer will help, and this PR should also show a benefit. Neither will help if DSP is continuously sending more logs than the log transport can handle, but for those case, move to DMA based logging (with probes) is the right solution.

Thanks, @kv2019i , I have already tried using the following configuration

CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD=1
CONFIG_LOG_PROCESS_THREAD_SLEEP_MS=10

but the issue in the zephyrproject-rtos/zephyr#105550 still persists.

Note: keeping as draft to get some CI feedback on this before marking ready for review.

That's good.