> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bota.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Streaming Upload

> Upload recording chunks while recording continues for faster transcription

Streaming Upload allows Bota devices to upload completed audio chunks to the cloud while recording continues. This significantly reduces time-to-insight for long recordings.

## Why Streaming Upload?

With traditional upload, the entire recording must finish before upload begins. For a 60-minute meeting, you wait 60 minutes of recording plus upload and processing time.

With streaming upload, chunks are uploaded as they're recorded. By the time the recording ends, most of the audio is already in the cloud and partially processed.

### Traditional Upload

```mermaid theme={null}
gantt
    title Traditional Upload (~67 min total)
    dateFormat X
    axisFormat %s

    section Pipeline
    Record           :0, 60
    Upload           :60, 62
    Transcribe       :62, 67
```

### Streaming Upload

```mermaid theme={null}
gantt
    title Streaming Upload (~62 min total)
    dateFormat X
    axisFormat %s

    section Pipeline
    Record + Upload  :0, 60
    Transcribe       :60, 62
```

## How It Works

The device uses **double buffering** — recording into one memory buffer while uploading the previous buffer:

1. Device records audio into Buffer A
2. When Buffer A is full (one chunk), swap to Buffer B
3. Upload Buffer A contents to S3 in the background
4. Continue recording into Buffer B
5. Repeat until recording ends
6. Call finalize to stitch chunks and trigger transcription

This requires only \~2.5 MB of device memory (two chunks) regardless of recording length, compared to storing the entire recording on-device.

## Connectivity

Streaming upload works across all [connectivity methods](/guides/connectivity):

| Path             | Network                    | How It Works                                                                                 | Best For                               |
| ---------------- | -------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------- |
| **WiFi Upload**  | Wi-Fi                      | Device uploads chunks directly to S3 over Wi-Fi                                              | Note, Pin/Pin Pro with WiFi configured |
| **4G Upload**    | Cellular                   | Device uploads chunks directly to S3 over cellular                                           | Pin, Pin Pro in the field              |
| **Wi-Fi Direct** | P2P Wi-Fi                  | Device streams to phone via Wi-Fi Direct, phone uploads                                      | Fast phone-mediated sync               |
| **BLE Sync**     | Bluetooth + phone internet | Device streams audio from in-memory ring buffer over Bluetooth to phone, phone uploads to S3 | Any device with phone nearby           |

All paths use the same backend API. For phone-mediated paths (BLE Sync, Wi-Fi Direct), the React Native SDK manages the transfer — the device streams from its ring buffer while still recording, with the SD card as a safe backup.

## Chunk Size

Choose chunk duration based on your use case:

| Chunk Duration | File Size (Opus 32kbps) | Trade-off                        |
| -------------- | ----------------------- | -------------------------------- |
| 1 minute       | \~250 KB                | Most real-time, highest overhead |
| **5 minutes**  | **\~1.25 MB**           | **Recommended — balanced**       |
| 10 minutes     | \~2.5 MB                | Fewer uploads, less overhead     |
| 15 minutes     | \~3.75 MB               | Ultra-long recordings only       |

Smaller chunks = faster feedback but more upload requests. 5 minutes is the recommended default.

## Use Cases

### Medical Documentation

A doctor records a 2-hour patient consultation. With streaming upload over WiFi, transcription starts during the appointment. By the time the doctor finishes, clinical notes are nearly ready.

### Legal Depositions

An attorney records a 4-hour deposition. Partial transcripts become available during breaks, allowing review and preparation for follow-up questions.

### Sales Calls

A sales rep records a 1-hour client meeting. CRM notes are auto-populated from the summary while the rep is still with the client.

## Bluetooth Streaming Sync

For BLE-only devices, the mobile app acts as the upload bridge using the React Native SDK:

1. Device records audio — encoder writes each frame to SD card and a 1 MB in-memory ring buffer
2. SDK initiates Bluetooth streaming for the in-progress recording
3. Device reads from the ring buffer and sends over Bluetooth (lower latency than SD card reads)
4. Phone buffers chunks and uploads to S3 as they fill
5. Recording stops — device drains remaining ring buffer data and sends EOF
6. Phone uploads final chunk and calls finalize

BLE streaming is an **optimization**, not a requirement. If Bluetooth disconnects, the recording continues safely on the device's SD card and can be batch-synced later.

| Scenario                                  | What Happens                                          |
| ----------------------------------------- | ----------------------------------------------------- |
| Bluetooth connected when recording starts | Live streaming via Bluetooth → phone → S3             |
| Bluetooth not connected                   | Normal recording to SD card, batch sync later         |
| Bluetooth drops mid-recording             | Recording continues on device, batch sync picks it up |
| App killed during streaming               | Same as Bluetooth drop — recording safe on SD card    |

## Error Handling

* **Failed chunk upload** — Device retries with exponential backoff, then queues locally for later
* **Missing chunks on finalize** — Backend reports which chunks are missing; device re-uploads them
* **Network switch mid-upload** — Device can switch between WiFi, cellular, and Bluetooth mid-recording using HTTP range requests to resume partial uploads

## Comparison

|                           | Traditional Upload                  | Streaming Upload                                      |
| ------------------------- | ----------------------------------- | ----------------------------------------------------- |
| **Device storage**        | Full recording (\~15 MB for 60 min) | 2 chunks (\~2.5 MB)                                   |
| **Upload timing**         | After recording ends                | During recording                                      |
| **Network**               | Any (BLE, WiFi, Cellular)           | Any (WiFi, Cellular, Wi-Fi Direct, Bluetooth via SDK) |
| **Time to transcription** | Recording + upload + processing     | Recording + \~2 min                                   |
| **Best for**              | Short recordings (\< 30 min)        | Long recordings (30+ min)                             |

## Related

* [Connectivity](/guides/connectivity) — All upload methods and failover behavior
* [Device Management](/guides/device-management) — Enable streaming in device settings
* [Cellular Mode](/guides/cellular-mode) — Combine streaming with 4G
* [Create Recording](/api-reference/recordings/create) — Create streaming recordings
* [Finalize Recording](/api-reference/recordings/finalize-streaming) — Complete streaming uploads