[FEAT] Offline Voice-to-Query (Local Whisper Integration)

[Adithyakp86]

🔴 Problem
The project currently supports Voice Output (TTS) but lacks Voice Input (STT). This limits accessibility for users in high-pressure legal environments who need to query the law database while handling physical documents. There is no way to perform a "hands-free" search for specific BNS/IPC sections.

✅ Proposed Solution
Whisper Integration: Add faster-whisper or whisper.cpp Python bindings for real-time, local transcription of user queries.
Streamlit Audio Pipeline: Implement a custom Streamlit component to capture microphone input and pipe it directly to the local model.
Semantic Routing: Develop a post-transcription logic that determines if the user is asking for a "Section Mapping" (IPC -> BNS) or a "General Search" (RAG) and routes the query automatically.

Assign this issue to me under OSCG .

[github-actions]

Thank you for raising this issue!

We'll review it as soon as possible. We truly appreciate your contributions! ✨

Meanwhile make sure you've visited the README.md, CONTRIBUTING.md, and CODE_OF_CONDUCT.md before creating a PR for this. Also, please do NOT create a PR until this issue has been assigned to you. 😊

[m13v]

nice architecture for the voice-to-query flow. a few notes on the whisper integration from building a similar pipeline:

faster-whisper is a solid choice over the standard openai-whisper package. it uses CTranslate2 under the hood which gives about 4x speedup on CPU. for a Streamlit app where users are waiting for results, that latency difference is very noticeable.

for the semantic routing (section mapping vs general search), feed the raw transcript directly to your routing logic rather than cleaning it up first. whisper sometimes produces artifacts like repeated phrases or hallucinated text at the start/end of short utterances. if you clean those before routing, the routing model sees cleaner input. a simple regex to strip common whisper artifacts (repeated "you know", trailing periods that whisper adds to silence) helps a lot.

on the Streamlit audio pipeline, streamlit-webrtc works for mic capture but has quirks with browser permissions. make sure you handle the case where the user denies mic access gracefully. also, whisper expects 16kHz mono Float32 audio, so you'll need a resampling step between the browser's default 48kHz capture and the model input.

[m13v]

the semantic routing after transcription is the trickiest part here. we built something similar where voice input needs to be classified as either a direct query or a specific action request. the approach that worked was running a lightweight intent classifier on the transcription text before sending it to the full LLM. for a legal tool like this, the patterns are actually pretty consistent: "what is the equivalent of IPC section 302" is clearly a mapping query, while "search for cases related to theft" is a RAG query. you could start with simple keyword heuristics (section numbers, "equivalent", "map" for mapping vs. open-ended phrases for RAG) and graduate to a classifier later. for the Whisper integration, faster-whisper with the small model is a good balance between speed and accuracy for legal terminology, but you might need to add a custom vocabulary file for BNS/IPC section numbers that the base model tends to hallucinate.

[m13v]

our voice transcription service with model selection and the intent classification pipeline that routes to different actions: https://github.com/m13v/fazm/blob/main/Desktop/Sources/TranscriptionService.swift

and the tool executor that handles the action routing after intent classification: https://github.com/m13v/fazm/blob/main/Desktop/Sources/Providers/ChatToolExecutor.swift