-
Notifications
You must be signed in to change notification settings - Fork 328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
_audio_in_queue
Getting Stucked and not getting the InputAudioRawFrame
coming from DailyInput
#721
Comments
Usually when this happens is becausse the If you are running a custom Pipecat (i.e. from the repo) would it be possible for you to re-raise the exception in the line mentioned in that bug report?
Does this happen with any specific function call or any of them? |
@aconchillo Usually what I have noticed that it happens when it uses |
@aconchillo We noticed sometimes it also occurs at the very start of the call as well. There is no specific pattern!!! |
@aconchillo No we are NOT using a fork pipecat |
@aconchillo Hard to reproduce. Any suggestion how to fix it? |
@aconchillo also as you pointed their is now exception being catch their as well so we never get to know!!! |
Description
It is a bug. At some point of a call following is happening:
InputAudioRawFrame
is pushed from DailyInputTransport_audio_in_queue
as_audio_task_handler
ofBaseInputTransport
is never able to get theInputAudioRawFrame
and bot becomes deaf as nothing is pushed in the VAD or the other Frames in the pipeline.Environment
Issue description
The issue is that, at some point, the
_audio_in_queue
stops receivingInputAudioRawFrame
objects, even though they are still being sent from Daily. We are not entirely sure why this happens. However, when it does, theInputAudioRawFrame
objects continue arriving from Daily but are not pushed into the asyncio queue. This essentially crashes the entire pipeline.You can observe in the logs that when this occurs, the
User-Started-Speaking
log statement is also not printed. Additionally, when a participant leaves, Pipecat cancels all tasks. Strangely, after this, we start seeing theUser-Started-Speaking
andUser-Stopped-Speaking
statements, which should have been logged earlier. Also the main task for pipecat bot is kept hanging running.My suspicion is that a task is not executing properly, which is causing a blockage in the queue.
Repro steps
The bug is difficult to reproduce as it occurs randomly. However, it is most often observed later in the call when the user asks a question, and a tool is invoked. Additionally, we noticed that when this bug happens, the TTS response is abruptly cut off in the middle.
Expected behavior
Actual behavior
Logs
2024-11-13T20:21:00.339
as you can see TTS service is in middle of saying and then we don't recieve anything else.We also added some logging statements in the pipecat source which leads us to the conclusion that no InputAudioRawFrames are placed in
_audio_in_queue
, following are the logs for that. As you can see that InputAudioFrame are coming from Daily but are not pushed in the pipeline:The text was updated successfully, but these errors were encountered: