Increase optimization parameters

[bebilli]

question1：Adding the functionality to print the time spent at each pipeline stage is beneficial for understanding the performance bottlenecks, so as to optimize the entire chain.
question2：When the STT recognizes the text, it is then sent to the LLM, and surprisingly, it takes a full second in between. I'm not sure where this one second is being spent. The log is as follows:
2025-04-10 00:44:44.681 | DEBUG | pipecat.services.local_stt:run_stt:121 - Transcription ==> [Are you okay? ]
2025-04-10 00:44:45.678 | DEBUG | pipecat.services.openai.base_llm:_stream_chat_completions:156 - LocalLLMService#0: Generating chat [[{"role": "system", "content": "\n \u4f60\u662f\u4e00\u4f4d\u540d\u4e3a{{char}}...

[markbackman]

For 1, noted as a feature request.

For 2, this is part of the user response algorithm. The goal is to avoid generating multiple completions when there are pending transcriptions that will occur. You can see that code here: https://github.com/pipecat-ai/pipecat/blob/main/src/pipecat/processors/aggregators/llm_response.py#L221. We're open to tuning the timing, but some type of waiting is actually helpful. This prevents two final transcripts from being received, both generating completions back to back, which could result in duplicate phrases from the LLM.

FYI: some of these questions are better for Discord. Feel free to join and we can discuss there: https://discord.gg/pipecat.

For maintainers: Marking this as an enhancement request for bullet 1.

[bebilli]

@markbackman question 3: Log Dyeing Function, It is recommended to add the context of the conversation to each log, such as session_id, trace_id, or request_id. Since this framework is asynchronous, adding these logs will make it easier to trace the logs under high concurrency, which is beneficial for debugging and tracking issues.

[markbackman]

For 1, the processing metrics are a good approximation of this.

For 3, we're adding tracing. Tracing is tracked through another option issue. Closing this.