Service issue
Pipecat version: 1.5.0; the same constructor default is present on current main
Service: AssemblyAI Streaming STT (AssemblyAISTTService)
Model: universal-3-5-pro
Issue description
AssemblyAISTTService does not inherit PipelineParams.audio_in_sample_rate when the service sample rate is omitted.
The base STTService supports pipeline sample-rate inference:
self._sample_rate = self._init_sample_rate or frame.audio_in_sample_rate
However, AssemblyAISTTService.__init__ declares sample_rate: int = 16000 and passes it to the base class. This always sets _init_sample_rate to 16000, preventing the StartFrame value from being used. In comparison, DeepgramSTTService declares sample_rate: int | None = None, so it inherits the pipeline rate as expected.
This is especially problematic for telephony. With raw 8 kHz PCM input and PipelineParams(audio_in_sample_rate=8000), AssemblyAI connects with sample_rate=16000 and computes its chunk size for 16 kHz, while the bytes are still 8 kHz PCM. There is no resampling in this path.
Reproduction steps
- Construct
AssemblyAISTTService without an explicit sample_rate.
- Run it in a pipeline configured with
PipelineParams(audio_in_sample_rate=8000).
- Inspect
service.sample_rate or the AssemblyAI WebSocket query after start().
- Observe that the declared sample rate is 16000 rather than 8000.
In a real telephony session this caused provider-reported audio duration to be almost exactly half the actual recording duration, along with severely degraded transcription and turn behavior. Passing sample_rate=8000 explicitly fixed the sample-rate mismatch.
Expected behavior
When sample_rate is omitted, AssemblyAISTTService should inherit StartFrame.audio_in_sample_rate, consistent with the base STTService, PipelineParams, and DeepgramSTTService.
An explicitly supplied service sample rate should continue to override the pipeline rate.
Suggested fix
Change the constructor default to:
sample_rate: int | None = None
and add coverage for:
- omitted service rate with an 8000 Hz
StartFrame -> 8000 Hz
- explicit service rate -> explicit value overrides
StartFrame
Service issue
Pipecat version: 1.5.0; the same constructor default is present on current
mainService: AssemblyAI Streaming STT (
AssemblyAISTTService)Model:
universal-3-5-proIssue description
AssemblyAISTTServicedoes not inheritPipelineParams.audio_in_sample_ratewhen the service sample rate is omitted.The base
STTServicesupports pipeline sample-rate inference:However,
AssemblyAISTTService.__init__declaressample_rate: int = 16000and passes it to the base class. This always sets_init_sample_rateto 16000, preventing theStartFramevalue from being used. In comparison,DeepgramSTTServicedeclaressample_rate: int | None = None, so it inherits the pipeline rate as expected.This is especially problematic for telephony. With raw 8 kHz PCM input and
PipelineParams(audio_in_sample_rate=8000), AssemblyAI connects withsample_rate=16000and computes its chunk size for 16 kHz, while the bytes are still 8 kHz PCM. There is no resampling in this path.Reproduction steps
AssemblyAISTTServicewithout an explicitsample_rate.PipelineParams(audio_in_sample_rate=8000).service.sample_rateor the AssemblyAI WebSocket query afterstart().In a real telephony session this caused provider-reported audio duration to be almost exactly half the actual recording duration, along with severely degraded transcription and turn behavior. Passing
sample_rate=8000explicitly fixed the sample-rate mismatch.Expected behavior
When
sample_rateis omitted,AssemblyAISTTServiceshould inheritStartFrame.audio_in_sample_rate, consistent with the baseSTTService,PipelineParams, andDeepgramSTTService.An explicitly supplied service sample rate should continue to override the pipeline rate.
Suggested fix
Change the constructor default to:
and add coverage for:
StartFrame-> 8000 HzStartFrame