Perfecte, Miquel. És una molt bona idea deixar-ho aquí i reprendre-ho amb calma més tard.
Aquí tens un resum tècnic exacte del punt on ens hem quedat, perquè quan tornis puguis copiar i engançar aquesta informació (o simplement llegir-la) i continuem sense perdre el fil.
📋 RESUM DE LA SITUACIÓ (Per continuar més tard)
🎯 Objectiu final: Enviar una petició amb text a un servei del Synology i que aquest generi automàticament un fitxer veu.wav amb la veu «Ona» i el guardi a la carpeta compartida /volume1/web/piper-ona-veu/.
✅ El que JA funciona:
El contenidor piper està engegat i funcionant correctament. (Vam haver d’arreglar un error de permisos fent sudo chmod -R 777 /volume1/docker/piper). Ara està «Ready» i escoltant internament al port 10200.
La carpeta de destí /volume1/web/piper-ona-veu/ està creada i accessible.
❌ El que hem descartat:
El contenidor flask-tts (port 5050). Hem descobert que intenta parlar amb piper mitjançant HTTP senzill, però piper utilitza el protocol Wyoming. Això provoca un error de connexió (Error 500). El deixarem de banda.
L’ús de Python directament al sistema operatiu del Synology per fer de «pont», ja que el Python del NAS no té pip ni les llibreries necessàries instal·lades.
⏸️ El punt d’aturada (On ens hem quedat): Estàvem creant un nou contenidor Docker propi anomenat tts-wrapper per fer de pont. La seva funció seria:
Escoltar peticions JSON al port 5051.
Connectar-se directament al contenidor piper (a través de la xarxa Docker flask_default) utilitzant la llibreria de Python wyoming.
Rebre l’àudio i guardar-lo a /data/veu.wav (que està mapejat a /volume1/web/piper-ona-veu/veu.wav).
L’última acció: Vam intentar construir i engegar aquest contenidor (docker build i docker run), però el contenidor no es va crear o va fallar silenciosament a l’arrencar (per això sortia «No such container»).
📌 DADES CLAU PER QUAN TORNIS
IP del Synology:192.168.1.49
Xarxa Docker on estan els contenidors:flask_default
Carpeta del projecte del wrapper:/volume1/docker/tts-wrapper/ (ha de contenir app.py i Dockerfile).
Carpeta de sortida de l’àudio:/volume1/web/piper-ona-veu/
🚀 PRÒXIMS PASSOS (Quan reprenguis la sessió)
Connecta’t per SSH al Synology.
Comprova que els fitxers app.py i Dockerfile existeixen a /volume1/docker/tts-wrapper/.
Torna a intentar la construcció amb sudo docker build -t tts-wrapper /volume1/docker/tts-wrapper i llegeix amb atenció l’última línia per veure si hi ha algun error de compilació (a vegades els Synology amb processadors ARM o antics necessiten una imatge base de Docker lleugerament diferent).
Si falla el build, t’ho dius i ajustem el Dockerfile. Si té èxit, l’engeguem i fem la prova final amb curl.
Descansa, Miquel! Quan vulguis continuar, només has de dir «reprenem» i ens posem directament amb el Pas 2 d’aquesta llista. Fins ara has fet una feina de diagnòstic excel·lent! 💪
Perfecte, Miquel — ara entenc exactament què vols:
👉 Que l’entrada del blog expliqui que NO cal obrir cap terminal, ni arrencar Python, ni entrar al servidor Flask. 👉 Només cal obrir el fitxer localTTS Piper (Ona).html, i aquest formulari ja envia el text al servidor Flask que està funcionant en segon pla gràcies a systemd. 👉 I que la URLhttp://127.0.0.1:5000només és visible en mode debug, però en l’ús normal no cal ni visitar-la.
Això és molt més elegant i molt més “user‑friendly”.
A continuació et deixo el text revisat perquè l’entrada del blog reflecteixi exactament aquest comportament.
Entrada des de formulari HTML per al servidor TTS (Ona, UPC) a Deepin del Docker
Aquesta entrada complementa la guia principal “Muntatge d’un servidor TTS local amb veu catalana (Ona, UPC) a Deepin” i explica com afegir-hi un formulari HTML extern que permet enviar text directament al servidor TTS sense obrir cap terminal.
L’objectiu és disposar d’un sistema molt simple d’usar: només cal obrir el fitxerTTS Piper (Ona).html i escriure el text. El servidor Flask ja està funcionant en segon pla gràcies a systemd.
🎯 Objectiu
Crear un servidor Flask que escolta a 127.0.0.1:5000/processa.
Fer que Flask s’iniciï automàticament en cada arrencada del sistema.
Crear un fitxer HTML local que envia text al servidor TTS.
Permetre que tot el sistema funcioni sense obrir Python, sense activar entorns virtuals, sense obrir cap terminal.
Fer que el sistema sigui reproduïble en qualsevol Deepin/Debian.
Aquí tens l’entrada de blog completa, llesta per publicar (en Markdown):
---
title: "Text del navegador a veu amb Piper TTS en Docker"
date: "2026-09-20"
tags: ["docker", "piper", "tts", "python", "flask"]
---
# Text del navegador a veu amb Piper TTS en Docker
Vols escriure text en una pàgina web i que es converteixi en àudio (WAV) amb una veu sintètica? En aquest post et mostro com muntar un **contenidor Docker** que fa exactament això: un HTML envia el text, i el contenidor el passa al **Piper** (motor de text-a-veu) per retornar-te el fitxer WAV directament al navegador.
## Arquitectura
El flux és senzill:
1. L'usuari escriu text a un formulari HTML.
2. JavaScript envia el text a una API (Flask) mitjançant `POST /api/tts`.
3. Flask executa `piper` dins del contenidor amb el text rebut.
4. Piper genera un fitxer `.wav`.
5. L'àudio es retorna al navegador i es reprodueix automàticament.
curl -X POST http://localhost:5000/api/tts \
-H "Content-Type: application/json" \
-d '{"text": "Hola, això és una prova"}' \
--output prova.wav
Alternativa: imatge ja preparada
Si no vols construir res, existeixen imatges com loderunner84/piper-rest (Flask + Piper). Ara bé, muntar-ho tu mateix et dona control total sobre el model, els endpoints i la interfície.
Conclusió
Amb quatre fitxers tens un servei de text-a-veu complet dins d’un contenidor Docker: text des del navegador entra, WAV en surt. Pots ampliar-lo fàcilment: suport de múltiples idiomes, cua de peticions o desar historial d’àudios. Bon blog i bona sintetització! 🎙️
---
Aquest és el post complet en Markdown. Si vols, puc:
1. **Adaptar-lo al teu blog** (canviar títol, tags, to, afegir captures).
2. **Traduir-lo al castellà** o a l'anglès.
3. **Crear la carpeta del post** perquè el desis directament (recorda que per crear fitxers necessito que em diguis com vols fer-ho, o t'obro l'editor).
Què prefereixes?
iquel@Miquel-PC:~$ docker exec piper bash -c «echo \»Hola, sóc l’Ona, la meva veu s’ha desenvolupat a la UPC de Barcelona.\» | piper –model /config/ca_ES-upc_ona-medium.onnx –output_file -» | aplay -f S16_LE -r 22050 -c 1 Playing WAVE ‘stdin’ : Signed 16 bit Little Endian, Rate 22050 Hz, Mono Miquel@Miquel-PC:~$ aquest issatge es reprodueix sense problemes amb el servidor local tts-server i Piper (ona) a Deepin. podries mostra el flux del texte fins arribar al altaveus?
Deep think completado (tardó 3s)
Aquí tens el flux complet del text fins als altaveus, pas a pas:
34DAC (convertidor digital→analògic) de la targeta de so
35 │
36 ▼
37Amplificador → Altaveus 🔊
38
38 líneas de código colapsadasExpandir
Detalls clau de cada etapa
docker exec — Executa el procés dins del contenidor piper, que conté el model i l’eina.
echo ... | piper — El text entra per stdin. Piper fa la síntesi amb el model neuronal ONNX ca_ES-upc_ona-medium:
El model converteix el text en una seqüència de fonemes (representació intermèdia).
La xarxa neuronal genera l’espectrograma mel (representació freqüencial de la veu).
El vocoder converteix aquest espectrograma en mostres d’àudio PCM.
--output_file - — L’àudio es treu per stdout en format PCM cru (sense capçalera WAV), a 22050 Hz, mono, 16 bits little-endian.
| aplay — La canonada passa aquest flux de dades a aplay de l’host:
-f S16_LE → interpreta les mostres com a enter amb signe de 16 bits little-endian.
-r 22050 → freqüència de mostreig.
-c 1 → un canal (mono).
ALSA → DAC → Altaveus — aplay entrega les mostres al subsistema de so del kernel; la targeta de so converteix les mostres digitals en senyal analògic, que l’amplificador fa arribar als altaveus.
Observació
El fet que funcioni així demostra que el contenidor genera àudio PCM cru a stdout i que el pipe el porta directament a l’ALSA de Deepin sense cap intermediari (sense PulseAudio/PipeWire pel mig), cosa que minimitza la latència. Si volguessis enregistrar-ho en un fitxer WAV, n’hi hauria prou amb afegir-hi una capçalera:
3 escriu el text ───────────────────────► llegeix de stdin
4
4 líneas de código colapsadasExpandir
echoescriu el text al seu stdout.
La canonada (|) connecta el stdout de echo amb el stdin de piper.
piperllegeix el text del seu stdin (com si vingués del teclat, però ve del pipe) i el processa.
És per això que el diagrama deia TEXT (stdin): el text entra a piper per aquest canal estàndard. Com que no especifiques cap fitxer d’entrada (--input_file), piper agafa les dades de stdin.
Per què s’escriu així?
| (pipe) → encadena processos: la sortida d’un és l’entrada del següent.
--output_file - → el guionet - és una convenció que significa «el mateix stdin/stdout en lloc d’un fitxer», és a dir, escriu l’àudio al stdout perquè després aplay el pugui rebre.
Resumint: stdin és simplement «el lloc per on piper rep el text d’entrada» — en aquest cas, a través del pipe des de echo.
Enrutamiento Inteligente
tic el problema que l’entrada nomès es llegeix si el missat té un minin de caracters, per example ‘teulada’ es perdria. qui pot ser el responsable?
Deep think completado (tardó 30s)
Molt bona pregunta. La resposta curta: el sospitós principal és aplay (o més exactament, com es gestiona el final del flux quan es llegeix d’un pipe), no pas Piper.
Per què?
Amb un text curt com teulada, Piper genera l’àudio correctament, però l’àudio és tan breu que tot el contingut pot quedar dins el buffer de la targeta de so sense arribar a sonar. La seqüència és:
plaintext
1piper genera poques dades ──► pipe ──► aplay escriu al buffer de ALSA
2 │
3 EOF (el contenidor acaba) ────────┤
4 ▼
5 aplay tanca el dispositiu de so
6 (snd_pcm_close) i descarta el que queda
7
7 líneas de código colapsadasExpandir
Quan aplay rep EOF pel stdin (perquè el contenidor ha acabat i el pipe es tanca), tanca el dispositiu de so immediatament, sovint sense esperar que el buffer de la targeta es buidi del tot. Amb missatges llargs, només es talla un tros final petit i no ho notes; amb teulada, l’àudio sencer pot estar al buffer i es perd.
Com confirmar-ho (diagnòstic ràpid)
Prova de guardar la sortida en un fitxer i reproduir-lo després:
(el sleep dins el contenidor fa que el pipe no es tanqui tan de pressa).
Prova primer el diagnòstic amb fitxer per confirmar-ho. Si vols, puc ajudar-te a muntar un script que gestioni automàticament el cas dels textos curts. Què prefereixes?
Molt revelador! Aquest missatge d’aplay és la clau del misteri:
plaintext
1Playing raw data ‘/tmp/teulada.wav’ : Unsigned 8 bit, Rate 8000 Hz, Mono
2
2 líneas de código colapsadasExpandir
Què vol dir aquest missatge?
aplay diu «raw data» amb format per defecte (U8, 8000 Hz, mono) — això és el que fa quan no troba cap capçalera WAV al fitxer. És a dir, el fitxer /tmp/teulada.wav és buit o gairebé buit (menys de 44 bytes).
Comparem amb el primer comandament, on deia:
plaintext
1Playing WAVE ‘stdin’ : Signed 16 bit Little Endian, Rate 22050 Hz, Mono
2
2 líneas de código colapsadasExpandir
Allà aplay sí va detectar la capçalera WAV. La diferència no és aplay: és que Piper no ha generat l’àudio per a «teulada».
El responsable: la segmentació de frases de Piper
Piper només sintetitza frases completes. Divideix el text en frases buscant puntuació de final de frase (., !, ?):
"Hola, sóc l'Ona... Barcelona." → acaba amb punt → frase completa → sintetitza ✅
"teulada" → no acaba amb cap puntuació → l’últim fragment es considera incomplet i es descarta a l’EOF ❌
És un comportament conegut de Piper: si el text no acaba amb ., ! o ?, no produeix cap sortida.
Prova el test de teulada. amb punt i digue’m si ja sona — si és així, el problema era exactament aquest.
Enrutamiento Inteligente
Miquel@Miquel-PC:~$ ls -l /tmp/teulada.wav # espera 0 bytes o < 44 -rw-rw-r– 1 Miquel Miquel 0 de set. 19 11:14 /tmp/teulada.wav Miquel@Miquel-PC:~$ docker exec piper bash -c «echo ‘teulada.’ | piper –model /config/ca_ES-upc_ona-medium.onnx –output_file -» > /tmp/teulada2.wav aplay /tmp/teulada2.wav # ara hauria de dir «Playing WAVE…» i sonar Playing raw data ‘/tmp/teulada2.wav’ : Unsigned 8 bit, Rate 8000 Hz, Mono Miquel@Miquel-PC:~$ no ha sonat encara que els altaveus han fet un sorollet?
Deep think completado (tardó 41s)
Aquest resultat descarta la hipòtesi de la puntuació: fins i tot amb teulada. no hi ha sortida. El «sorollet» que has sentit és simplement el clic de la targeta de so en obrir-se i tancar-se sense rebre dades — aplay no va reproduir res perquè el fitxer era buit (o quasi).
On som ara
Prova
Resultat
Conclusió
teulada (sense punt)
0 bytes
Piper no genera res
teulada. (amb punt)
«raw data» → buit
La puntuació no és la causa
Missatge llarg original
«Playing WAVE» ✅
Piper funciona amb text llarg
El sospitós ha canviat: Piper no genera cap sortida per a textos curts (o bé docker exec perd la sortida petita). Cal separar aquestes dues possibilitats.
Si el fitxer dins el contenidor té > 0 bytes → Piper funciona; el problema és el stdout de docker exec (buffering/truncament per sortides petites).
Si és 0 bytes → Piper mateix descarta els textos curts.
Diagnòstic 3: Troba el llindar
bash
1for T in «teulada» «Hola» «Hola Ona» «Hola Ona, com estas» «Aquesta es una frase normal» «Aquesta es una frase una mica mes llarga per provar el sistema»; do
Executa el diagnòstic 1 i 2 i digue’m els resultats — amb això ja sabrem si el culpable és Piper o el canal de sortida de docker exec. Segons el resultat, la solució serà ben diferent:
Piper no genera res → caldrà ajustar com es passa el text (potser la versió de piper del contenidor té un mínim de caràcters, o requereix un paràmetre com --sentence-silence o forçar l’última frase).
docker exec perd la sortida → la solució serà escriure a un fitxer dins el contenidor i fer docker cp, o afegir sleep al final perquè docker exec flushegi.
Resultat molt important! Això canvia completament el diagnòstic:
Prova
Resultat
--output_file - (stdout)
0 bytes
--output_file /tmp/test.wav (fitxer)
28.204 bytes ✅
Piper SÍ que sintetitza «teulada.» perfectament (28 KB ≈ 0,6 s d’àudio). El problema no és la síntesi: és que el canal de sortida per stdout (--output_file -) a través de docker exec es perd.
Què passa exactament?
Quan el text és curt, la síntesi és tan ràpida que el contenidor acaba abans que docker exec hagi flushejat/entregat la sortida de stdout, i el flux es tanca amb 0 bytes. Amb el text llarg, hi ha prou temps/dades perquè la sortida arribi bé — per això el primer comandament va funcionar.
No és culpa de Piper (sintetitza bé), sinó de la combinació stdout + docker exec per a processos que acaben molt de pressa.
Comprovacions per confirmar-ho
1. El text llarg encara surt per stdout?
bash
1docker exec piper bash -c «echo \»Hola, sóc l’Ona, la meva veu s’ha desenvolupat a la UPC de Barcelona.\» | piper –model /config/ca_ES-upc_ona-medium.onnx –output_file -» | wc -c
2
2 líneas de código colapsadasExpandir
Si dóna >0, confirma que és una qüestió de temps/mida de la sortida.
2. Hi ha un fitxer anomenat - dins el contenidor?
bash
1docker exec piper bash -c «ls -la»
2
2 líneas de código colapsadasExpandir
(Per descartar que piper interpreti - com a nom de fitxer.)
Solució robusta (recomanada)
Ja que sabem que escriure a fitxer funciona sempre, la solució fiable és generar el WAV dins del contenidor i copiar-lo fora:
El sleep 1 fa que el contenidor no surti immediatament i la sortida de stdout arribi sencera.
Prova primer la comprovació 1 (text llarg per wc) per confirmar la teoria, i després la solució amb docker cp que és la que et resoldrà el problema de manera definitiva. Què surt?
Enrutamiento Inteligente
Miquel@Miquel-PC:~$ aplay /tmp/veu.wav Playing WAVE ‘/tmp/veu.wav’ : Signed 16 bit Little Endian, Rate 22050 Hz, Mono Miquel@Miquel-PC:~$ #!/bin/bash # tts.sh «text a dir» TEXT=»${1:?Ús: tts.sh ‘text’}» [[ «$TEXT» =~ [.!?]$ ]] || TEXT=»$TEXT.» docker exec piper bash -c «echo \»$TEXT\» | piper –model /config/ca_ES-upc_ona-medium.onnx –output_file /tmp/veu.wav» docker cp piper:/tmp/veu.wav /tmp/veu.wav aplay /tmp/veu.wav bash: 1: Ús: tts.sh text bash: !?]$ ]] || TEXT=»$TEXT.»: event not found Traceback (most recent call last): File «/lsiopy/bin/piper», line 6, in <module> sys.exit(main()) ~~~~^^ File «/lsiopy/lib/python3.14/site-packages/piper/__main__.py», line 251, in main with wav_file: ^^^^^^^^ File «/usr/lib/python3.14/wave.py», line 477, in __exit__ self.close() ~~~~~~~~~~^^ File «/usr/lib/python3.14/wave.py», line 595, in close self._ensure_header_written(0) ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^ File «/usr/lib/python3.14/wave.py», line 613, in _ensure_header_written raise Error(‘# channels not specified’) wave.Error: # channels not specified Successfully copied 1.54kB to /tmp/veu.wav Playing raw data ‘/tmp/veu.wav’ : Unsigned 8 bit, Rate 8000 Hz, Mono Miquel@Miquel-PC:~$ el primer bash ha dit ‘teulada’ el segon només un sorollet
Deep think completado (tardó 15s)
Perfecte! El que has fet és enganxar el script línia a línia al terminal interactiu, i això ha provocat dos errors clàssics:
Què ha passat
bash: !?]$ ]]...: event not found → El terminal interactiu de bash interpreta !? com a expansió d’historial (buscar l’última comanda que contingui aquest text). Per això la línia del regex ha esclatat. En un fitxer de script això no passa (l’expansió d’historial només actua al terminal).
wave.Error: # channels not specified → Com que l’assignació de $TEXT va fallar (no hi havia argument), Piper va rebre text buit i va petar en intentar tancar el WAV. El docker cp va copiar un fitxer antic/parcial (1,54 kB) i aplay el va reproduir com a dades brutes → el «sorollet».
2~/tts.sh «Hola, sóc l’Ona, la meva veu s’ha desenvolupat a la UPC de Barcelona.»
3
3 líneas de código colapsadasExpandir
Per què aquesta versió funciona
case en comptes de regex → evita el problema del ! (l’expansió d’historial no s’activa dins d’un fitxer).
El text es passa com a argument ($1), no enganxat al mig.
La síntesi va a un fitxer (/tmp/veu.wav), que és el mètode que hem verificat que sempre funciona (28 KB per a «teulada.»), i després docker cp el porta a l’host perquè aplay el reprodueixi.
Si vols confirmar la teoria del stdout perdut, també pots provar això (hauria de donar >0):
bash
1docker exec piper bash -c «echo \»Hola, sóc l’Ona, la meva veu s’ha desenvolupat a la UPC de Barcelona.\» | piper –model /config/ca_ES-upc_ona-medium.onnx –output_file -» | wc -c
2
2 líneas de código colapsadasExpandir
Prova el script i digue’m si ja parla l’Ona correctament! 🗣️
Enrutamiento Inteligente
Miquel@Miquel-PC:~$ ~/tts.sh «teulada» ~/tts.sh «Hola, sóc l’Ona, la meva veu s’ha desenvolupat a la UPC de Barcelona.» Successfully copied 30.2kB to /tmp/veu.wav Playing WAVE ‘/tmp/veu.wav’ : Signed 16 bit Little Endian, Rate 22050 Hz, Mono Successfully copied 214kB to /tmp/veu.wav Playing WAVE ‘/tmp/veu.wav’ : Signed 16 bit Little Endian, Rate 22050 Hz, Mono Miquel@Miquel-PC:~$ perfecte. els dos van bé
Deep think completado (tardó 2s)
Molt bé! 🎉 L’Ona ja parla sense problemes, tant per a paraules curtes (teulada → 30,2 kB) com per a frases llargues (214 kB).
Resum del problema i la solució
Causa arrel: el canal de sortida per stdout (--output_file -) a través de docker exec perdia les dades quan la síntesi acabava massa de pressa (textos curts). No era culpa ni de Piper ni de aplay.
Solució final: generar el WAV dins del contenidor, copiar-lo amb docker cp i reproduir-lo amb aplay. Així sempre funciona, sigui quin sigui el llarg del text.
El teu script ~/tts.sh queda com a base sòlida per al teu servidor TTS.
Millores opcionals (si vols)
Evitar el docker cp — Si recrees el contenidor, pots muntar un volum compartit i escriure-hi directament:
24 return jsonify({«error»: «falta el camp ‘text'»}), 400
25 audio = sintetitza(text)
26 return Response(audio, mimetype=»audio/wav»)
27
27 líneas de código colapsadasExpandir
Amb això, una petició POST /tts amb {"text": "teulada"} retornaria el WAV directament, i tu decideixes si el client el reprodueix o el servidor ho fa amb aplay.
Expliqueu-me com és el teu tts-server i t’ho adapto exactament. 🙂
Enrutamiento Inteligente
demana’m la informació que vulguis
Deep think completado (tardó 5s)
Gràcies per la captura! Ja veig que és un projecte Python amb venv, uns scripts de prova (prova_piper.py, prova_piper_dbg.py) i una subcarpeta tts-server/. Per integrar-hi el pipeline correctament, necessito que em responguis això:
Preguntes
1. Ruta absoluta del projecte Quina és la ruta completa del directori? (p. ex. /home/Miquel/tts-server/) — Així puc llegir els fitxers directament i veure el codi real.
2. On és el codi principal del servidor?
El servidor en si és dins la subcarpeta tts-server/? (quins fitxers hi ha?)
O prova_piper.py / prova_piper_dbg.py són els scripts que fas servir?
3. Quin framework utilitza? Flask? FastAPI? http.server de Python? Sockets?
4. Quina interfície exposa?
Port i endpoints (p. ex. POST /tts al port 5000)
Què rep (JSON amb text?) i què retorna (àudio WAV? només OK? text?)
5. Com l’arrenques? python server.py? Un servei systemd? Docker?
6. El venv/ és el que utilitza el servidor? I quin Python hi ha dins (venv/bin/python --version)?
Un cop em diguis la ruta absoluta, puc llegir prova_piper.py, server.log i el contingut de tts-server/ per adaptar-ho exactament al teu codi, sense suposar res.
Enrutamiento Inteligente
ubicació: /home/Miquel/tts-server
Execution ProcessProcessed for 24s
Perfecte, ara llegeixo els fitxers per veure el codi real.
Deep think completado (tardó 8s)
Ja tinc una visió clara! Llegeixo els fitxers de prova i el log: el teu tts-server és en realitat un servidor speech-to-speech (STT amb Parakeet + VAD + TTS amb Piper) que escolta al port 10200 i parla per socket amb missatges JSON (synthesize, audio-start, audio-chunk, audio-stop).
Els fitxers server.py/app.py dins la subcarpeta no existeixen (m’ha dit «Paràmetre no vàlid»). Deixa’m localitzar el codi real del servidor.
Deep think completado (tardó 3s)
La subcarpeta tts-server/ i piper-config/ existeixen, però no puc llistar-ne el contingut directament des d’aquí (només en veig les metadades). Necessito que em mostris l’arbre de fitxers per localitzar el codi del servidor.
Executa això al terminal i enganxa’m la sortida
bash
1find /home/Miquel/tts-server -maxdepth 4 -type f | sort
2
2 líneas de código colapsadasExpandir
Amb la llista de fitxers podré llegir el codi exacte on es crida Piper dins del servidor (el que ara deu fer servir --output_file - i pateix el problema dels textos curts) i adaptar-hi la solució robusta del fitxer + docker cp.
El codi del servidor no és un projecte local: és un paquet Python instal·lat al venv (el binari speech-to-speech i el log ho confirmen — paquet speech_to_speech). El find amb -maxdepth 4 no arriba fins a site-packages, per això no el veus.
Executa això per localitzar el codi on es crida Piper:
bash
1find /home/Miquel/tts-server/venv/lib/python3.12/site-packages/speech_to_speech -type f -name «*.py» | sort
La primera comanda et donarà l’estructura del paquet; la segona, quins fitxers concrets fan servir Piper (allà hi haurà el codi que hem de modificar per arreglar els textos curts). Enganxa’m la sortida.
Interessant! Al paquet speech_to_speechno hi ha cap handler de Piper (només chatTTS, facebookmms, kokoro, pocket_tts, qwen3). Però el teu client prova_piper.py fa servir la veu ca_ES-upc_ona-medium (Piper) i funciona. Deixa’m llegir els fitxers clau per veure com es connecta Piper i on es genera l’àudio.
Deep think completado (tardó 8s)
El paquet speech_to_speech instal·lat és el pipeline complet (VAD → STT → LLM → TTS amb chatTTS/facebookMMS/pocket/kokoro/qwen3), però no conté cap handler de Piper ni el protocol JSON que fa servir el teu prova_piper.py (missatges synthesize, audio-chunk, port 10200).
Això vol dir que el teu servidor a 10200 és un codi propi que no he trobat encara. Necessito localitzar-lo.
Executa aquestes comandes i enganxa’m la sortida
1. Trobar el codi que implementa el protocol (synthesize / audio-chunk / 10200):
Amb això sabré on és el codi del servidor que hem de modificar (on es crida Piper amb --output_file -) per canviar-lo a la solució robusta del fitxer + docker cp.
La cerca dins de /home/Miquel/tts-server no ha trobat res, així que el codi del servidor de 10200 és en un altre lloc. Necessito les altres dues comandes per localitzar-lo:
La comanda 2 és clau: mostrarà la línia de comandes completa del procés que escolta al port 10200, i amb això sabré exactament quin script i des de quina ruta s’executa.
Enrutamiento Inteligente
tampoc trova res.
Deep think completado (tardó 3s)
Cap problema. Necessito les comandes de processos per veure què escolta al port 10200. Executa aquestes:
1. Quin procés escolta al port 10200?
bash
1ss -tlnp | grep 10200
2
2 líneas de código colapsadasExpandir
2. Processos Python/speech en marxa:
bash
1ps aux | grep -v grep | grep -E «python|speech|piper»
2
2 líneas de código colapsadasExpandir
3. Si no hi ha res en marxa, busca el codi en llocs habituals fora del home:
La comanda 1 és la més directa: et dirà el PID i la línia de comandes exacta del servidor que atén les peticions de prova_piper.py. Si el servidor no està en marxa ara mateix, digues-m’ho i busquem el codi per un altre camí (p. ex. history o nohup.out).
Ara ho veig tot clar! 🎯 El teu «tts-server» és en realitat wyoming-piper: el servidor de TTS de Home Assistant (protocol Wyoming) executant-se dins del contenidor piper:
I el teu prova_piper.py parla el protocol Wyoming (missatges synthesize, audio-start, audio-chunk, audio-stop).
Això canvia la perspectiva de la integració: el servidor wyoming-piper no passa per docker exec --output_file - (fa servir Piper internament), així que el problema de «teulada» aquí és probablement un altre: la puntuació final de frase. Recorda que mai vam aclarir del tot si Piper requereix el punt final — ho hem de verificar.
Prova 1: Piper requereix el punt final? (dins el contenidor)
15 total += m[«data»][«bytes»]; f.read(m[«data»][«bytes»])
16 elif m.get(«type») == «audio-stop»: break
17 s.close()
18 print(f»{texto!r}: {total} bytes d’àudio»)
19
20test(«teulada»)
21test(«teulada.»)
22EOF
23
23 líneas de código colapsadasExpandir
Què esperem
Si Prova 1: t1 = 0 i t2 > 0 → Piper exigeix punt final.
Si Prova 2: «teulada» = 0 i «teulada.» > 0 → el servidor falla per falta de puntuació, i la integració consistirà a fer que wyoming-piper afegeixi el punt automàticament (per exemple amb un wrapper al binari piper dins del contenidor).
Executa les dues proves i enganxa’m els resultats.
Resultat molt aclaridor! Ambdues opcions generen àudio:
Text
Fitxer
Bytes
teulada (sense punt)
t1.wav
42.540 ✅
teulada. (amb punt)
t2.wav
28.204 ✅
Piper no requereix punt final — la hipòtesi de la puntuació queda descartada. Els 0 bytes del principi eren només el problema del stdout de docker exec.
Ara falta la Prova 2 (la que et vaig donar): comprovar si el servidor wyoming-piper (port 10200) respon amb àudio per a «teulada». Executa-la:
bash
1python3 – <<‘EOF’
2import socket, json
3
4def test(texto):
5 s = socket.create_connection((«127.0.0.1», 10200), timeout=10)
15 total += m[«data»][«bytes»]; f.read(m[«data»][«bytes»])
16 elif m.get(«type») == «audio-stop»: break
17 s.close()
18 print(f»{texto!r}: {total} bytes d’àudio»)
19
20test(«teulada»)
21test(«teulada.»)
22EOF
23
23 líneas de código colapsadasExpandir
Això ens dirà si el servidor ja funciona per a textos curts (i llavors la integració és al teu client/script) o si cal arreglar wyoming-piper.
Enrutamiento Inteligente
Miquel@Miquel-PC:~$ python3 – <<‘EOF’ import socket, json def test(texto): s = socket.create_connection((«127.0.0.1», 10200), timeout=10) f = s.makefile(«rwb») evt = json.dumps({«type»: «synthesize», «data»: {«text»: texto, «voice»: «ca_ES-upc_ona-medium»}}) f.write((evt + «\n\n»).encode()); f.flush() total = 0 while True: h = f.readline() if not h: break m = json.loads(h) if m.get(«type») == «audio-chunk»: total += m[«data»][«bytes»]; f.read(m[«data»][«bytes»]) elif m.get(«type») == «audio-stop»: break s.close() print(f»{texto!r}: {total} bytes d’àudio») test(«teulada») test(«teulada.») EOF Traceback (most recent call last): File «<stdin>», line 19, in <module> File «<stdin>», line 12, in test File «/usr/lib/python3.12/json/__init__.py», line 346, in loads return _default_decoder.decode(s) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File «/usr/lib/python3.12/json/decoder.py», line 341, in decode raise JSONDecodeError(«Extra data», s, end) json.decoder.JSONDecodeError: Extra data: line 1 column 62 (char 61) Miquel@Miquel-PC:~$
Deep think completado (tardó 33s)
El test ha fallat amb un error de JSON: «Extra data: line 1 column 62». Això vol dir que la primera línia que torna el servidor no és un sol objecte JSON — hi ha més dades enganxades, o el format real de la resposta és diferent del que assumíem. Necessito veure la resposta crua del servidor per entendre el protocol real.
El repr() et mostrarà els bytes exactes que envia el servidor (incloent salts de línia i caràcters de control). Amb això veuré si:
El servidor espera un handshake previ (p. ex. un event describe primer, com fa el protocol Wyoming estàndard)
O la resposta té un format diferent del que fa servir el teu prova_piper.py
Recorda que prova_piper.pyno l’hem vist funcionar mai en aquesta conversa — potser el protocol del servidor real és diferent del que assumeix el teu client.
1. Bona notícia: el servidor wyoming-piper SÍ que genera àudio per a «teulada»! 🎉 Ha respost amb audio-start i audio-chunk — el problema dels textos curts era només del camí docker exec --output_file -, no del servidor.
2. El teu prova_piper.py parla un protocol incorrecte. El protocol Wyoming real separa capçalera (amb data_length) i payload (els bytes següents). El teu client assumia que la línia JSON contenia les dades directament (data: {bytes: N}) — per això petaria en llegir la resposta.
La integració: un client Wyoming correcte
Guarda aquest script (reemplaça el protocol erroni):
2python3 /home/Miquel/tts-server/tts_wyoming.py «Hola, sóc l’Ona, la meva veu s’ha desenvolupat a la UPC de Barcelona.»
3
3 líneas de código colapsadasExpandir
Aquest client parla el protocol real de wyoming-piper: envia synthesize amb capçalera correcta (data_length), llegeix audio-start → audio-chunk → audio-stop, guarda el WAV i el reprodueix amb aplay. El servidor ja fa la seva feina; el que faltava era el client correcte. Prova-ho i digue’m si l’Ona parla tant els textos curts com els llargs!
Enrutamiento Inteligente
així es pot esborrar prova_piper.py?
Deep think completado (tardó 6s)
Sí! Pots esborrar-los tranquil·lament — tts_wyoming.py els substitueix:
prova_piper.py — protocol Wyoming incorrecte (assumia data: {bytes: N} dins la capçalera) → obsolet.
prova_piper_dbg.py — mateix protocol incorrecte, només amb logs → també obsolet.
Per seguretat, en comptes d’esborrar-los, els moc a una carpeta de còpia de seguretat (així si algun dia els necessites, hi són):
Deep think completado (tardó 1s)
Fet! ✅ Els dos scripts antics han quedat moguts a:
plaintext
1/home/Miquel/tts-server/backup_scripts/
2├── prova_piper.py
3└── prova_piper_dbg.py
4
4 líneas de código colapsadasExpandir
Estructura final de tts-server/
Fitxer/carpeta
Estat
tts_wyoming.py
✅ El client correcte (protocol Wyoming real)
piper-config/
Models de Piper
tts-server/
Subcarpeta amb còpies
venv/
Entorn Python
server.log
Logs
backup_scripts/
Antics scripts (obsolets)
Si ho vols netejar del tot, ara pots esborrar la carpeta backup_scripts amb rm -r — o deixar-la com a còpia de seguretat.
Recorda que l’únic que necessites fer servir d’ara endavant és:
El script connecta a wyoming-piper (port 10200) i envia synthesize amb el text teulada.
El servidor sintetitza (recorda que ja vam veure que respon amb audio-start + audio-chunk per a textos curts).
Veuràs un missatge com: plaintext 1OK: /tmp/veu_wyoming.wav (XXXXX bytes, 22050 Hz)22 líneas de código colapsadasExpandir
Llavors aplay reproduirà el WAV i hauries de sentir «teulada» 🔊
Si surt el OK i sona, ja tenim la integració completa funcionant amb textos curts. Digue’m què passa!
Enrutamiento Inteligente
Miquel@Miquel-PC:~$ python3 /home/Miquel/tts-server/tts_wyoming.py «teulada» Traceback (most recent call last): File «/home/Miquel/tts-server/tts_wyoming.py», line 54, in <module> main() File «/home/Miquel/tts-server/tts_wyoming.py», line 31, in main t, payload = read_event(f) ^^^^^^^^^^^^^ File «/home/Miquel/tts-server/tts_wyoming.py», line 19, in read_event meta = json.loads(line) ^^^^^^^^^^^^^^^^ File «/usr/lib/python3.12/json/__init__.py», line 341, in loads s = s.decode(detect_encoding(s), ‘surrogatepass’) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File «/usr/lib/python3.12/encodings/utf_16_le.py», line 16, in decode return codecs.utf_16_le_decode(input, errors, True) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ UnicodeDecodeError: ‘utf-16-le’ codec can’t decode byte 0x0a in position 444: truncated data decoding with ‘utf-16-le’ codec failed Miquel@Miquel-PC:~$
Deep think completado (tardó 47s)
L’error ens dona una pista clau: json.loads ha rebut una línia de més de 444 bytes plena de binaris (per això detecta UTF-16). Això vol dir que la lectura s’ha desincronitzat: hem llegit àudio cru com si fos una capçalera. La meva suposició sobre el camp data_length dels audio-chunk deu ser incorrecta.
Necessito veure la seqüència completa d’esdeveniments. Executa aquesta depuració que mostra cada capçalera i el seu payload:
2├── data_length (61) → JSON de metadades (rate/width/channels/timestamp)
3└── payload_length (2048) → L’ÀUDIO REAL
4
4 líneas de código colapsadasExpandir
El meu client només llegia data_length (61 bytes de metadades) i ignorava els 2048 bytes d’àudio que venen després — per això la lectura es desincronitzava i llegia àudio cru com a capçalera.
Quan vols muntar un servidor TTS local amb la veu catalana Ona (UPC), tens dues opcions: instal·lar Piper directament al sistema o encapsular-lo dins un contenidor Docker. A Deepin —i en general a qualsevol Linux— Docker aporta una sèrie de beneficis molt clars, però també alguns punts a tenir en compte.
Aquesta entrada resumeix els avantatges i inconvenients reals de tenir Piper dins Docker, basats en experiència pràctica.
🟦 Avantatges de tenir Piper (Ona) dins Docker
1. Aïllament total del sistema
Docker encapsula Piper en un entorn propi:
no depèn del Python del sistema
no depèn de llibreries de Deepin
no es trenca amb actualitzacions del sistema
no interfereix amb altres projectes Python
És com tenir un “mini‑Linux” dedicat només al TTS.
2. Servei permanent i autoreiniciable
Amb --restart unless-stopped, Piper:
arrenca automàticament quan encens Deepin
es reinicia si peta
queda sempre disponible al port 10200
Això el converteix en un servei TTS del sistema, no en un script puntual.
És molt més segur que executar scripts directament.
🟥 Inconvenients de tenir Piper (Ona) dins Docker
⭐ cal un altre contenidor Docker amb un altre port per a la veu Pau, cada veu necessita un contenidor
PIPER_VOICE=nom_del_model.onnx
No pot canviar de veu “en calent”.
No pot tenir diverses veus carregades simultàniament.
Wyoming TTS només exposa la veu carregada.
Això vol dir que si vols tenir Ona + Pau disponibles alhora, necessites:
piper_ona → port 10200
piper_pau → port 10201
I el teu servidor local (port 8765) pot triar a quin contenidor enviar el text.
1. Requereix Docker instal·lat i actiu
Si Docker no arrenca, Piper tampoc. És un punt feble si el servei Docker falla (poc habitual).
2. Consum lleugerament superior
Un contenidor té:
filesystem propi
processos aïllats
un petit overhead
És mínim, però existeix.
3. Cal entendre mínimament Docker
Per gestionar Piper:
docker ps
docker logs
docker run
volums i ports
No és complicat, però és un aprenentatge.
4. Accés als fitxers més “indirecte”
Els models estan dins /config (volum Docker). No és un inconvenient greu, però és diferent de tenir-los al sistema directament.
5. Depens del contenidor concret
Si el mantenidor del contenidor deixa d’actualitzar-lo, caldria:
canviar d’imatge
o muntar Piper manualment
Actualment, linuxserver/piper és fiable.
🟦 Conclusió
Tenir Piper (Ona) dins Docker és, en la majoria de casos, la millor opció: estable, modular, segura i fàcil de mantenir. Els inconvenients són menors comparats amb els avantatges, especialment en sistemes com Deepin on les dependències de Python poden ser problemàtiques.
Docker converteix Piper en un servei TTS permanent, sempre disponible, actualitzable i aïllat del sistema.
Si vols, Miquel, puc preparar una versió HTML d’aquesta entrada perquè la puguis enganxar directament al WordPress, o afegir-hi una secció final amb comandes recomanades per gestionar el contenidor Piper.
Perfecte, Miquel — et deixo els passos exactes i ordenats per afegir la veu Piper (Pau) en un nou contenidor Docker, tal com ho fas amb Ona. Això és just el que necessites per continuar la teva entrada del blog i per tenir Ona + Pau funcionant alhora.
Aquí tens la guia pas a pas 👇
⭐ Guia per afegir la veu Pau en un altre contenidor Docker
01
Descarrega el model de la veu Pau
Preparació
Cal tenir el fitxer ONNX de la veu Pau dins la carpeta de models que ja utilitzes amb Ona.
Ves a la pàgina oficial de models de Piper
Descarrega ca_ES-upc_pau-medium.onnx (o la versió que prefereixis)
Copia el fitxer a: /home/Miquel/tts/models/
02
Verifica que el model està dins el volum
Important
El contenidor Piper utilitza /config com a volum, que en el teu cas correspon a /home/Miquel/tts.
Comprova que tens: /home/Miquel/tts/models/ca_ES-upc_pau-medium.onnx
Si tens subcarpetes, assegura que el nom coincideix exactament amb el model
03
Crea el nou contenidor Piper per a Pau
Contenidor nou
Cada veu necessita el seu propi contenidor perquè Piper només pot carregar una veu per instància.
Si tens Ona i Pau, pots alternar enviant a 10200 o 10201
⭐ Resum final
Sí, per afegir la veu Pau cal un altre contenidor Docker.
Piper només pot carregar una veu per contenidor.
Amb Ona (10200) + Pau (10201) tindràs dues veus disponibles alhora.
El teu servidor local pot triar a quin contenidor enviar el text.
Si vols, puc preparar-te també els passos per afegir Aina, Carlota o qualsevol altra veu, o fins i tot un script Bash que arrenca totes les veus automàticament quan encens Deepin.
En aquesta entrada veurem com crear un petit servidor local en Python capaç de rebre text enviat des d’un navegador i retornar-lo immediatament al mateix navegador. És un exemple senzill però molt útil per entendre com funcionen les peticions HTTP, els formularis HTML i la comunicació amb un servidor local.
Formulari per enviar el text:
<!DOCTYPE html>
<html lang="ca">
<head>
<meta charset="UTF-8">
<title>Enviar text al servidor Python</title>
</head>
<body>
<h1>Enviar text al servidor local Python</h1>
<form action="http://127.0.0.1:5000/processa" method="post">
<label for="text">Text:</label>
<input type="text" id="text" name="text">
<button type="submit">Enviar</button>
</form>
</body>
</html>
1️⃣ Preparar l’entorn: Python i Flask
A Deepin 25 (o qualsevol distribució basada en Debian), pip no permet instal·lar paquets directament al sistema. Per això cal crear un entorn virtual.
Instal·lar venv (si cal)
bash
sudo apt install python3-venv
Crear l’entorn virtual
bash
python3 -m venv ~/flask-env
Activar-lo
bash
source ~/flask-env/bin/activate
El terminal hauria de mostrar:
Codi
((flask-env))
Instal·lar Flask dins l’entorn
bash
pip install flask
2️⃣ Crear el servidor local en Python
Creem un fitxer anomenat server.py amb (nano server.py) i enganxar:
I tant. La manera més senzilla és fer que el navegador enviï el text a un servidor local Python, i aquest executi Docker/Piper. Així no cal donar al navegador accés directe al terminal.
1. Servidor Python
Crea servidor.py: servidor.py
from http.server import BaseHTTPRequestHandler, HTTPServer
import subprocess
import json
HOST = "127.0.0.1"
PORT = 8765
class Handler(BaseHTTPRequestHandler):
def do_POST(self):
if self.path != "/parlar":
self.send_error(404)
return
try:
length = int(self.headers.get("Content-Length", 0))
data = json.loads(self.rfile.read(length))
text = data.get("text", "").strip()
if not text:
self.send_error(400, "Text buit")
return
# Executem Piper dins del contenidor.
# El text entra per stdin, evitant problemes amb cometes.
cmd = [
"docker", "exec", "-i", "piper",
"piper",
"--model", "/config/ca_ES-upc_ona-medium.onnx",
"--output_file", "-"
]
piper = subprocess.Popen(
cmd,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE
)
audio, error = piper.communicate(
text.encode("utf-8"),
timeout=60
)
if piper.returncode != 0:
raise RuntimeError(error.decode("utf-8", errors="replace"))
# Reproduïm el PCM generat per Piper.
subprocess.run(
["aplay", "-f", "S16_LE", "-r", "22050", "-c", "1"],
input=audio,
check=True
)
response = {"ok": True}
self.send_response(200)
self.send_header("Content-Type", "application/json")
self.send_header("Access-Control-Allow-Origin", "*")
self.end_headers()
self.wfile.write(json.dumps(response).encode())
except Exception as e:
print("ERROR:", e)
self.send_response(500)
self.send_header("Content-Type", "application/json")
self.send_header("Access-Control-Allow-Origin", "*")
self.end_headers()
self.wfile.write(
json.dumps({"ok": False, "error": str(e)}).encode()
)
def do_OPTIONS(self):
self.send_response(204)
self.send_header("Access-Control-Allow-Origin", "*")
self.send_header("Access-Control-Allow-Methods", "POST, OPTIONS")
self.send_header("Access-Control-Allow-Headers", "Content-Type")
self.end_headers()
print(f"Ona preparada a http://{HOST}:{PORT}")
HTTPServer((HOST, PORT), Handler).serve_forever()
i envio el text per stdin. És millor perquè frases amb apòstrofs, cometes, accents, signes d’interrogació, etc. no trenquen el comandament.
Si vols, el següent pas pot ser fer-te una versió molt més bonica, tipus consola d’assistent, amb botó 🎙️, historial de converses, indicador que l’Ona està parlant i resposta automàtica, mantenint Piper dins del teu Docker.
Sí. Et passo el llistat complet de tots els fitxers i ubicacions que hem identificat en aquesta configuració, incloses còpies, configuracions, models i fitxers de prova.
Deep think completado (tardó 3s)
