The problem
The three stages are useful separately and useful chained. So the API exposes both: individual endpoints for transcription, response and synthesis, plus a single /converse endpoint that runs the whole pipeline in one multipart request - which keeps the round trip short enough to feel like a conversation.
What I built
- Built a FastAPI backend exposing four endpoints - /transcribe, /respond, /tts, and /converse chaining the full pipeline in a single multipart request.
- Integrated the Groq API using Llama 4 Scout for concise completions, with a configurable token limit and a graceful fallback response when the model call fails.
- Implemented speech-to-text with SpeechRecognition and text-to-speech with gTTS, returning replies as base64-encoded MP3 for direct in-browser playback.
- Developed a Streamlit interface with dual input modes - in-browser microphone recording and file upload - plus audio preview, adjustable reply length and error handling.
Stack
PythonFastAPIUvicornStreamlitSpeechRecognitiongTTSGroq API (Llama 4 Scout)audio-recorder-streamlitpython-dotenv
Skills applied
- Audio-to-text pipelines
- Text-to-speech synthesis
- LLM chat integration
- Multipart file handling
- REST API design
- Base64 audio encoding
- Streamlit UI development