- Expédié
- 29 septembre 2026 à 02:32 UTC
- Auteur
- Kamo
- Commite
- 16db29f
L'adaptateur code dur output format=mp3 44100 128 sur chaque appel, donc un appelant demander E5 pour wav (ou kamoai-voice demandant pcm, sur chaque appel téléphonique) toujours retour mp3 — un décodage extra lossy plus un resample sur le chemin d'appel, et un violation silencieuse du contrat pour tout autre appelant de /api/ai/v1/audio/speech. synthétiser() map maintenant AudioController's response format to ElevenLabs' own output format: pcm/wav fetch pcm 24000 (la propre convention PCM de AIService, Correspondant au code dur de 24 kHz de kamoai-voice) avec wave enveloppé dans un réel En-tête RIFF/WAVE ici (ElevenLabs n'en envoie jamais), mp3 garde mp3 44100 128, opus maps to opus 48000 128, et une ulaw maps explicite to ulaw 8000. Un format OnzeLabs ne peut pas parler (aac, flac) est refusé à l'avant donc le routeur tombe retour à un modèle qui peut, au lieu de l'erreur silencieuse en mp3. Les déclaré mimeType correspond toujours aux octets retournés, pas n'importe quoi Type de contenu que le vendeur a envoyé. kamoai-voice demande déjà pcm et lit le Type de Contenu déclaré d'AIService Au lieu de faire confiance à sa propre demande, aucun changement n'était nécessaire : PCM réel, à taux correspondant maintenant au lieu d'un mp3 décodé et rééchantillonné. Tests (SpeechVendorFamiliesTest, rouge puis vert contre un faux OnzeLabs serveur): chaque carte response format au bon format de sortie, le wav wrapper est un en-tête RIFF/WAVE valide de 44 octets autour des octets PCM intacts, un format non pris en charge est rejeté avant tout appel HTTP, et mp3 est inchangé.