Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

A podcast refuses on a tight machine rather than voicing at a smaller chunk

Abierto
  • ¿Algo no está bien?
#1,982 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@Yogi-cy ya está trabajando en esto.

Desde el 5/10/2026.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend

Línea de trabajo

Read the audio.cpp request and session options first to establish how chunk size is configured, then trace check_voicing_memory() in memory.py through _wait_for_memory() and _voice_each() in speech.py. Start with a failing test in test_speech.py; handle models with no chunk_steps and update the catalog documentation. Verify real-model behavior with test_audiocpp_voicing.py and listen to a two-speaker podcast at each enabled step.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

desktop enhancement help wanted

The gap

docs/architecture/local-models/catalog.md lists this under Known gaps:

The audio block's chunk_steps are committed but nothing reads them: short of memory at the default chunk, a podcast refuses rather than stepping down, until a listening test clears the smaller chunks.

Why it matters

Kokoro peaks at 2,347 MB while voicing at the default chunk, and at 1,442 MB at 120 characters and 956 MB at 60. Those numbers were measured on audio.cpp v0.8.2, reviewed and committed. A machine with two and a half gigabytes free is refused a podcast it could produce at half the memory, and the refusal instead suggests a different, lighter model — a worse answer than the same model voicing more slowly.

The manifest rule this page states is that an entry carries only fields some engine reads, precisely so nothing is reviewed and trusted while doing nothing. chunk_steps has been that field since it was added, and the memory check is one argument away from using it.

Where

What done looks like

  • A machine short of memory at the default chunk voices at the largest committed step that fits, rather than refusing, and a model with no steps still refuses with the sentence it gives today.
  • The refusal, when it comes, accounts for the smallest step, not the default peak — otherwise the numbers in the message are wrong.
  • The listening test is part of this issue, not a follow-up. Voice a two-speaker podcast at each step you enable and confirm the audio holds up; say in the PR what you listened to and on which audio.cpp build. A step that degrades the audio should not be enabled however well it fits.
  • Delete the Known gaps line from docs/architecture/local-models/catalog.md in the same PR, and update the chunk_steps bullet under The manifest so it describes a field that is read.

How to verify

surfsense_local/backend/tests/unit/llm/providers/audiocpp/test_speech.py drives voicing against a mock transport with an injectable available callable, so every memory branch is a unit test with no audio involved. tests/packaging/test_audiocpp_voicing.py is the real-model harness, gated on SURFSENSE_TEST_AUDIO_MODELS. The repo is TDD: write the failing unit test first.

cd surfsense_local/backend
uv run pytest -m unit
uv run pytest -m integration
uv run ruff check .

Before you start

Read CONTRIBUTING.md, the local model catalog doc and the Studio doc, which owns the podcast job this serves. Say up front whether you can run audio.cpp with a real model; without that the listening test cannot be done and the issue cannot be finished. Open your PR against dev, not main. Comment here to claim this.

Lenguaje dominante
Python
Estrellas
16.3k
Forks
1.6k
Merge medio
9 h 15 min
PR fusionados (30 d)
254

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MODSetter/SurfSense

Todos los issues de MODSetter/SurfSense

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.