feat(pipecat): upgrade pipecat-ai 1.1.0 → 1.5.0, daily-python 0.28 → 0.30#892
Open
swaroopvarma1 wants to merge 1 commit into
Open
feat(pipecat): upgrade pipecat-ai 1.1.0 → 1.5.0, daily-python 0.28 → 0.30#892swaroopvarma1 wants to merge 1 commit into
swaroopvarma1 wants to merge 1 commit into
Conversation
…> 0.30 Motivated by the widget Daily voice-mode crackling investigation: 1.1.0 is missing a series of upstream audio-quality fixes shipped in 1.2.x-1.5.0. This bump picks up: - SOXR resampler quality setting actually applied (1.3.0, upstream #4551) - BaseOutputTransport no longer reorders frames with equal PTS (1.3.0) - 200-300ms audible mixer gap on interruption fixed (1.4.0) - SOXRStreamAudioResampler clears stale state after gaps (1.5.0, #4886) - daily-python 0.30.0: audio playout thread use-after-free/segfault fixes, virtual-mic publishing segfault fix (0.28.1) Migration notes: - pipecat-ai-flows is deprecated/frozen upstream and now ships inside pipecat-ai as pipecat.flows (same API). Dependency removed; all pipecat_flows imports rewritten to pipecat.flows. - parse_telephony_websocket now returns a typed, dict-compatible CallData model: inbound/IVR/transfer signatures retyped dict -> CallData (runtime .get()/[] access unchanged). - FunctionCallParams grew a required pipeline_worker field: the MCP synthetic-params construction passes None like the existing llm/context. - AnthropicLLMAdapter.get_llm_invocation_params requires enable_prompt_caching: observers pass False (one-shot calls). - LLM settings values are now typed possibly-NOT_GIVEN: chat llm_driver narrows system_instruction to str | None before adapter calls. - FlowManager task= kwarg deprecated: switched to worker= (same object). - FlowsFunctionSchema.handler is now required (app code always passed it; test stub updated). Behavior changes inherited (intentional): - TTSSpeakFrame.append_to_context defaults to True: agent-mode greetings / fillers are now recorded in the LLM context. Stream mode (widget voice) has no assistant aggregator, so it is unaffected. - Flows initial node follows its context strategy (APPEND default) instead of always replacing: pre-inference greeting text is preserved. Verified: pyrefly 0 errors; 574 passed, 1 xfailed; all breeze_buddy voice modules import cleanly on 1.5.0. Follow-up for beta: re-verify AIC noise filter model files against aic-sdk 2.5.0 (fail-open if incompatible). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JMS9AtnyXQXHADd1ca1TwK
|
Warning Review limit reached
Next review available in: 47 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (14)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
swaroopvarma1
pushed a commit
that referenced
this pull request
Jul 14, 2026
Part 3 of the widget voice crackle fix (after #891 chunk sizing and #892 pipecat 1.5.0). Daily bots ran via asyncio.create_task inside the single-worker FastAPI process, so the 10ms-paced audio writer competed with every HTTP request, chat turn, and other call on one event loop — the root cause of intermittent agent-voice crackling (underruns concealed by the browser as glitches). A native daily-python crash could also take down the whole API pod. start_daily_session now spawns services/daily/bot_runner.py as a per-call OS process running the exact same daily_bot code path. Gated by the BB_DAILY_BOT_SUBPROCESS dynamic config (DevCycle/Redis -> env -> default), DEFAULT ON; flipping it to false is the no-restart escape hatch back to the legacy in-process launch (affects new calls only). - The launch payload (room_url, token, lead/session ids) travels over stdin, never argv, so the Daily token is not visible in `ps`. - The child inherits the environment, with POSTGRES_POOL_SIZE=1 / POSTGRES_MAX_OVERFLOW=2 overrides (init_db_pool eagerly opens min_size connections; a per-call child must not open the API pod's full pool). Override via BB_VOICE_BOT_DB_POOL_SIZE / BB_VOICE_BOT_DB_MAX_OVERFLOW. - Child stdout/stderr are inherited, so its loguru output (same colored-dev / JSON-prod config, driven by the inherited ENVIRONMENT) lands in the same container log stream; log context (lead_id, call_sid, conversation_id) is set inside the bot exactly as before. - A log-only reaper records the child's exit code; dead-bot recovery stays with the existing safety nets (/voice/end crash-net channel flip, 1h room expiry) — identical to a dead in-process task before. No functionality changes: every bot<->API coordination path is already process-agnostic (DB writes, the cross-process Redis session lock, DB-backed approvals, the Daily room itself), and every resource the bot needs is a lazy singleton (asyncpg pool, Redis) or env-driven. Applies uniformly to widget DAILY_STREAM, demo, and dashboard daily bots. Known deltas: bot join gains ~2-3s (child interpreter + imports; warm pool is a follow-up if it matters), each call adds one process (own ONNX copies) and 1-3 Postgres connections — size pods accordingly. Verified: pyrefly 0 errors; 583 passed, 1 xfailed (9 new tests: stdin payload round-trip incl. child-side parse, spawn args/env/stdin contract, escape-hatch fallback to in-process); bot_runner smoke-tested via `python -m` (invalid payload exits 2 with a clean error log). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JMS9AtnyXQXHADd1ca1TwK
swaroopvarma1
pushed a commit
that referenced
this pull request
Jul 14, 2026
Part 3 of the widget voice crackle fix (after #891 chunk sizing and #892 pipecat 1.5.0). Daily bots ran via asyncio.create_task inside the single-worker FastAPI process, so the 10ms-paced audio writer competed with every HTTP request, chat turn, and other call on one event loop — the root cause of intermittent agent-voice crackling (underruns concealed by the browser as glitches). A native daily-python crash could also take down the whole API pod. start_daily_session now spawns services/daily/bot_runner.py as a per-call OS process running the exact same daily_bot code path. Gated by the BB_DAILY_BOT_SUBPROCESS dynamic config (DevCycle/Redis -> env -> default), DEFAULT ON; flipping it to false is the no-restart escape hatch back to the legacy in-process launch (affects new calls only). - The launch payload (room_url, token, lead/session ids) travels over stdin, never argv, so the Daily token is not visible in `ps`. - The child inherits the environment, with POSTGRES_POOL_SIZE=1 / POSTGRES_MAX_OVERFLOW=2 overrides (init_db_pool eagerly opens min_size connections; a per-call child must not open the API pod's full pool). Override via BB_VOICE_BOT_DB_POOL_SIZE / BB_VOICE_BOT_DB_MAX_OVERFLOW. - Child stdout/stderr are inherited, so its loguru output (same colored-dev / JSON-prod config, driven by the inherited ENVIRONMENT) lands in the same container log stream; log context (lead_id, call_sid, conversation_id) is set inside the bot exactly as before. - A log-only reaper records the child's exit code; dead-bot recovery stays with the existing safety nets (/voice/end crash-net channel flip, 1h room expiry) — identical to a dead in-process task before. No functionality changes: every bot<->API coordination path is already process-agnostic (DB writes, the cross-process Redis session lock, DB-backed approvals, the Daily room itself), and every resource the bot needs is a lazy singleton (asyncpg pool, Redis) or env-driven. Applies uniformly to widget DAILY_STREAM, demo, and dashboard daily bots. Known deltas: bot join gains ~2-3s (child interpreter + imports; warm pool is a follow-up if it matters), each call adds one process (own ONNX copies) and 1-3 Postgres connections — size pods accordingly. Verified: pyrefly 0 errors; 583 passed, 1 xfailed (9 new tests: stdin payload round-trip incl. child-side parse, spawn args/env/stdin contract, escape-hatch fallback to in-process); bot_runner smoke-tested via `python -m` (invalid payload exits 2 with a clean error log). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JMS9AtnyXQXHADd1ca1TwK
swaroopvarma1
pushed a commit
that referenced
this pull request
Jul 14, 2026
Part 3 of the widget voice crackle fix (after #891 chunk sizing and #892 pipecat 1.5.0). Daily bots ran via asyncio.create_task inside the single-worker FastAPI process, so the 10ms-paced audio writer competed with every HTTP request, chat turn, and other call on one event loop — the root cause of intermittent agent-voice crackling (underruns concealed by the browser as glitches). A native daily-python crash could also take down the whole API pod. start_daily_session now spawns services/daily/bot_runner.py as a per-call OS process running the exact same daily_bot code path. Gated by the BB_DAILY_BOT_SUBPROCESS dynamic config (DevCycle/Redis -> env -> default), DEFAULT ON; flipping it to false is the no-restart escape hatch back to the legacy in-process launch (affects new calls only). - The launch payload (room_url, token, lead/session ids) travels over stdin, never argv, so the Daily token is not visible in `ps`. - The child inherits the environment, with POSTGRES_POOL_SIZE=1 / POSTGRES_MAX_OVERFLOW=2 overrides (init_db_pool eagerly opens min_size connections; a per-call child must not open the API pod's full pool). Override via BB_VOICE_BOT_DB_POOL_SIZE / BB_VOICE_BOT_DB_MAX_OVERFLOW. - Child stdout/stderr are inherited, so its loguru output (same colored-dev / JSON-prod config, driven by the inherited ENVIRONMENT) lands in the same container log stream; log context (lead_id, call_sid, conversation_id) is set inside the bot exactly as before. - A log-only reaper records the child's exit code; dead-bot recovery stays with the existing safety nets (/voice/end crash-net channel flip, 1h room expiry) — identical to a dead in-process task before. No functionality changes: every bot<->API coordination path is already process-agnostic (DB writes, the cross-process Redis session lock, DB-backed approvals, the Daily room itself), and every resource the bot needs is a lazy singleton (asyncpg pool, Redis) or env-driven. Applies uniformly to widget DAILY_STREAM, demo, and dashboard daily bots. Known deltas: bot join gains ~2-3s (child interpreter + imports; warm pool is a follow-up if it matters), each call adds one process (own ONNX copies) and 1-3 Postgres connections — size pods accordingly. Verified: pyrefly 0 errors; 583 passed, 1 xfailed (9 new tests: stdin payload round-trip incl. child-side parse, spawn args/env/stdin contract, escape-hatch fallback to in-process); bot_runner smoke-tested via `python -m` (invalid payload exits 2 with a clean error log). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JMS9AtnyXQXHADd1ca1TwK
swaroopvarma1
pushed a commit
that referenced
this pull request
Jul 14, 2026
Part 3 of the widget voice crackle fix (after #891 chunk sizing and #892 pipecat 1.5.0). Daily bots ran via asyncio.create_task inside the single-worker FastAPI process, so the 10ms-paced audio writer competed with every HTTP request, chat turn, and other call on one event loop — the root cause of intermittent agent-voice crackling (underruns concealed by the browser as glitches). A native daily-python crash could also take down the whole API pod. start_daily_session now spawns services/daily/bot_runner.py as a per-call OS process running the exact same daily_bot code path. Gated by the BB_DAILY_BOT_SUBPROCESS dynamic config (DevCycle/Redis -> env -> default), DEFAULT ON; flipping it to false is the no-restart escape hatch back to the legacy in-process launch (affects new calls only). - The launch payload (room_url, token, lead/session ids) travels over stdin, never argv, so the Daily token is not visible in `ps`. - The child inherits the environment, with POSTGRES_POOL_SIZE=1 / POSTGRES_MAX_OVERFLOW=2 overrides (init_db_pool eagerly opens min_size connections; a per-call child must not open the API pod's full pool). Override via BB_VOICE_BOT_DB_POOL_SIZE / BB_VOICE_BOT_DB_MAX_OVERFLOW. - Child stdout/stderr are inherited, so its loguru output (same colored-dev / JSON-prod config, driven by the inherited ENVIRONMENT) lands in the same container log stream; log context (lead_id, call_sid, conversation_id) is set inside the bot exactly as before. - A log-only reaper records the child's exit code; dead-bot recovery stays with the existing safety nets (/voice/end crash-net channel flip, 1h room expiry) — identical to a dead in-process task before. No functionality changes: every bot<->API coordination path is already process-agnostic (DB writes, the cross-process Redis session lock, DB-backed approvals, the Daily room itself), and every resource the bot needs is a lazy singleton (asyncpg pool, Redis) or env-driven. Applies uniformly to widget DAILY_STREAM, demo, and dashboard daily bots. Known deltas: bot join gains ~2-3s (child interpreter + imports; warm pool is a follow-up if it matters), each call adds one process (own ONNX copies) and 1-3 Postgres connections — size pods accordingly. Verified: pyrefly 0 errors; 583 passed, 1 xfailed (9 new tests: stdin payload round-trip incl. child-side parse, spawn args/env/stdin contract, escape-hatch fallback to in-process); bot_runner smoke-tested via `python -m` (invalid payload exits 2 with a clean error log). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JMS9AtnyXQXHADd1ca1TwK
swaroopvarma1
pushed a commit
that referenced
this pull request
Jul 14, 2026
Part 3 of the widget voice crackle fix (after #891 chunk sizing and #892 pipecat 1.5.0). Daily bots ran via asyncio.create_task inside the single-worker FastAPI process, so the 10ms-paced audio writer competed with every HTTP request, chat turn, and other call on one event loop — the root cause of intermittent agent-voice crackling (underruns concealed by the browser as glitches). A native daily-python crash could also take down the whole API pod. start_daily_session now spawns services/daily/bot_runner.py as a per-call OS process running the exact same daily_bot code path. Gated by the BB_DAILY_BOT_SUBPROCESS dynamic config (DevCycle/Redis -> env -> default), DEFAULT ON; flipping it to false is the no-restart escape hatch back to the legacy in-process launch (affects new calls only). - The launch payload (room_url, token, lead/session ids) travels over stdin, never argv, so the Daily token is not visible in `ps`. - The child inherits the environment, with POSTGRES_POOL_SIZE=1 / POSTGRES_MAX_OVERFLOW=2 overrides (init_db_pool eagerly opens min_size connections; a per-call child must not open the API pod's full pool). Override via BB_VOICE_BOT_DB_POOL_SIZE / BB_VOICE_BOT_DB_MAX_OVERFLOW. - Child stdout/stderr are inherited, so its loguru output (same colored-dev / JSON-prod config, driven by the inherited ENVIRONMENT) lands in the same container log stream; log context (lead_id, call_sid, conversation_id) is set inside the bot exactly as before. - A log-only reaper records the child's exit code; dead-bot recovery stays with the existing safety nets (/voice/end crash-net channel flip, 1h room expiry) — identical to a dead in-process task before. No functionality changes: every bot<->API coordination path is already process-agnostic (DB writes, the cross-process Redis session lock, DB-backed approvals, the Daily room itself), and every resource the bot needs is a lazy singleton (asyncpg pool, Redis) or env-driven. Applies uniformly to widget DAILY_STREAM, demo, and dashboard daily bots. Known deltas: bot join gains ~2-3s (child interpreter + imports; warm pool is a follow-up if it matters), each call adds one process (own ONNX copies) and 1-3 Postgres connections — size pods accordingly. Verified: pyrefly 0 errors; 583 passed, 1 xfailed (9 new tests: stdin payload round-trip incl. child-side parse, spawn args/env/stdin contract, escape-hatch fallback to in-process); bot_runner smoke-tested via `python -m` (invalid payload exits 2 with a clean error log). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JMS9AtnyXQXHADd1ca1TwK
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Part 2 of the widget Daily voice-mode crackling fix (part 1: #891). Our pinned pipecat 1.1.0 + daily-python 0.28.0 are missing a series of upstream audio-quality and stability fixes shipped through 1.5.0:
BaseOutputTransportno longer reorders frames with equal PTSSOXRStreamAudioResamplerclears stale state after gaps (#4886)Migration (1.1.0 → 1.5.0)
pipecat-ai-flowsremoved — upstream deprecated/froze the standalone package; Flows now ships inside pipecat-ai aspipecat.flowswith the same API. Allpipecat_flowsimports rewritten.CallData—parse_telephony_websocketreturns a dict-compatible Pydantic model; inbound/IVR/transfer signatures retypeddict→CallData(runtime.get()/[]access unchanged).FunctionCallParams.pipeline_worker(new required field) — MCP synthetic params passNone, same contract as the existingllm/contextfields (never read byMCPClient._tool_wrapper).AnthropicLLMAdapter.get_llm_invocation_paramsnow requiresenable_prompt_caching— observers passFalse(one-shot calls).llm_drivernarrowssystem_instructiontostr | None.FlowManager(task=…)deprecated →worker=(same object).FlowsFunctionSchema.handlernow required — app code always passed it; test stub updated.Inherited behavior changes (intentional, reviewed)
TTSSpeakFrame.append_to_contextnow defaultsTrue: agent-mode greetings/fillers are recorded in the LLM context (previously situation-dependent). Widget stream mode has no assistant aggregator → unaffected.APPENDdefault) instead of always replacing — pre-inference greeting context is preserved.Verified
uv run pyrefly check— 0 errorsuv run pytest— 574 passed, 1 xfailedDailyTransportClient.leave/cleanup/_leave/_cleanup) verified present in 1.5.0AICFilter(license_key=…, model_path=…)signature unchangedFollow-ups
aic-sdk2.5.0 (init is fail-open — worst case the filter is skipped with a warning). Only affects templates withnoise_filter.enable.🤖 Generated with Claude Code
https://claude.ai/code/session_01JMS9AtnyXQXHADd1ca1TwK