Skip to content

general_plan.md

Latest commit

 

History

History
86 lines (52 loc) · 5.19 KB

general_plan.md

File metadata and controls

86 lines (52 loc) · 5.19 KB

Техническая архитектура Hi-Res Audio Streaming Service

1. Концепция системы

Прототип децентрализованного (в плане вычислений) стриминга, переносящий нагрузку по декодированию тяжелых форматов (FLAC 24-bit/192kHz) с сервера на клиент через WebAssembly.

2. Компоненты системы

А. Бэкенд (Go + Fiber)

Роль: Хранилище контента и контроллер доступа.

  • Слой хранения: Организация медиатеки в виде блочного хранилища (файловая система/S3).
  • Стриминг-модуль: Поддержка HTTP Range Requests (стандарт RFC 7233) для частичной загрузки аудио-файлов.
  • Слой безопасности: Валидация прав доступа (JWT/Session) перед стримингом сырого бинарного потока.
  • API Метаданных: Отдача JSON с характеристиками трека (Sample Rate, Bit Depth, FLAC-заголовки).

Б. Фронтенд (Next.js)

Роль: Оркестрация потока данных и интерфейс.

  • Transport Layer: Реализация буферизированной загрузки чанков данных через Fetch API + ReadableStream.
  • Wasm Bridge: Загрузка, инициализация и управление памятью Rust-модуля.
  • Audio Pipeline: Управление контекстом Web Audio API. Использование AudioWorklet для безразрывного (gapless) воспроизведения в отдельном низкоприоритетном потоке.

В. Декодер (Rust + WebAssembly)

Роль: Низкоуровневая бинарная обработка.

  • Demuxer: Выделение метаданных и разметка границ фреймов из входящего байтового потока.
  • LPC Engine: Математическое восстановление сигнала на основе коэффициентов линейного предсказания (Linear Predictive Coding).
  • Bit-depth Transformer: Преобразование 24-битных целочисленных сэмплов в 32-битные с плавающей точкой (f32) для корректного восприятия браузером.

3. Алгоритм работы (Data Pipeline)

Шаг 1: Инициализация

  1. Клиент запрашивает метаданные трека.
  2. Сервер возвращает параметры (частота, битность) и токен доступа.
  3. Клиент настраивает AudioContext на целевую частоту (например, 192кГц).

Шаг 2: Потоковая передача

  1. Клиент запрашивает первый фрагмент файла (0-N байт).
  2. Сервер проверяет права и стримит бинарный поток.
  3. Байты передаются в общую память (SharedArrayBuffer) между JS и Wasm.

Шаг 3: Декодирование (Цикл)

  1. Поиск синхрокода: Rust-модуль ищет маркер начала фрейма FLAC 11111111 111110.
  2. Парсинг заголовка фрейма: Извлечение информации о размере блока.
  3. Восстановление (LPC): * Расчет остатка (residual).
  • Применение формулы предсказания: .
  1. Вывод: Формирование PCM-буфера.

Шаг 4: Воспроизведение

  1. Декодированные PCM-данные передаются в AudioWorkletProcessor.
  2. Планирование воспроизведения (Scheduling) с микросекундной точностью для исключения щелчков.
  3. Вывод на системное аудио-устройство.

4. Схема развертывания

  • Контейнеризация: Docker-образ с мультистадийной сборкой (сборка Go-бинарника и Next.js статики).
  • Оркестрация: Docker Compose (App + Nginx/Traefik для терминирования TLS).

5. Технические ограничения и решения

  • Ограничение: Браузеры могут ограничивать Sample Rate.
  • Решение: Анализ AudioContext.sampleRate и программный ресемплинг в Rust, если устройство вывода не поддерживает 192кГц.
  • Ограничение: Большой вес Hi-Res файлов.
  • Решение: Опережающее кширование (Look-ahead buffering) следующего чанка данных во время декодирования текущего.