[Bug] : Thread-Safety + Blocking I/O in Audio Writing

[nikhil1205-ai]

problem

The current implementation of audio recording in AudioSink.write() performs blocking disk I/O (wave.writeframes) inside a synchronized lock, which can significantly degrade performance under real-time audio conditions.

From your AudioSink.write():

with self._lock:
    writer = self._user_writers[user_id]
    writer.writeframes(data)

Why This Is a Serious Problem

1. Blocking I/O inside real-time audio pipeline

• writeframes() is blocking disk I/O

So:

• While writing → thread is blocked
• Incoming audio packets may queue or drop

2. Single global lock = bottleneck

• self._lock = threading.Lock()

This means:

• ALL users share ONE lock
• If 1 user writes → others wait

Result:

• Audio lag
• Data loss
• Poor scalability for multiple speakers

3. Not designed for high concurrency

In real Discord voice:

Multiple users speak simultaneously
Audio packets arrive rapidly

Your design = serial processing
Required = parallel / buffered processing

Proposed Solution

Introduce a queue-based buffering system with a background worker thread to decouple audio ingestion from disk I/O.

Suggested Approach:

• Use a thread-safe queue to collect audio packets:
• self._queue = queue.Queue()
• Modify write() to enqueue data instead of writing directly:
• self._queue.put((user_id, user, data))
• Process writes in a separate worker thread:

def _worker(self):
    while True:
        item = self._queue.get()
        if item is None:
            break
        # handle writing here

• Start worker thread during initialization and cleanly shut it down during cleanup().

Benefits

• Eliminates blocking I/O from the audio callback path
• Improves performance and scalability
• Reduces risk of audio packet loss
• Makes the system more production-ready