Gradium, Phonon cihaz üzeri TTS motorunu açık kaynak yaptı; asıl zor kısım gerçek zamanlı ses

Gradium, cihaz üzeri metinden sese motoru Phonon'u açık kaynak yaptı. dev.to'da yazan Dima Kruglov'a göre bu yayının önemi altta yatan modelden çok, verdiği sinyalde: konuşma sentezi artık bir lab demosu olarak değil, bir dependency olarak teslim edilebilir durumda ve onu benimseyen ekipler zorluğun modelde değil, seste olduğunu görecek.

Ses beklemeyen bir saatle çalışır

Web trafiği yavaşlığa tahammül eder; ses çalma etmez. Bir stream başladığında dijital-analog dönüştürücü örnekleri sabit bir hızda tüketir ve sentez döngüsünün önünde kalması gerekir. Yeterince geride kalırsanız output buffer boşalır; tıkırtılar, patlamalar ya da dinleyicinin arıza olarak algıladığı robotik bir kekemelik ortaya çıkar. Kruglov'a göre hesap şöyle: 24 kHz'de ve 20 ms'lik mixer periyoduyla her callback 480 örnek teslim etmeli — sürekli olarak; CPU ısınma nedeniyle throttle ederken ve işletim sistemi arka planda senkronizasyon yaparken bile.

Bu, nelerin optimize edileceğini de değiştirir. Makaleye göre medyan gecikme neredeyse anlamsızdır. Önemli olan en kötü durum chunk süresidir, çünkü tek bir yavaş chunk duyulabilir bir artefakta dönüşür; dakikalar boyunca sürdürülen, saniyeler değil, gerçek zaman faktörüdür, çünkü CPU governor'ları hızı düşürür; ve slack, yani en kötü chunk ile buffer'a önceden yüklenmiş ses arasındaki boşluktur.

Gerçek zaman faktörü bir ortalamadır ve ortalamalar başarısızlıkları gizler

Gerçek zaman faktörü — sentez süresinin ses süresine bölümü — herkesin alıntıladığı sayıdır ama tek başına yanıltıcıdır. Yazar, bir motorun bir dakika boyunca 0.55 RTF tutturup SoC işi büyük çekirdeklerden küçük çekirdeklere taşıyıp geri taşımadığı için dördüncü dakikada 1.1'e kaydığını anlatıyor. Beş saniyelik bir RTF ölçümü bunu tamamen gözden kaçırırdı. Makale, gerçek donanımda on dakikadan uzun süre çalışan ve ortalama RTF'nin yanına 99. yüzdelik ile en kötü durum chunk sürelerini ve buffer slack'inin pozitif kalıp kalmadığını raporlayan bir Python harness'i içeriyor — önemli nokta şu: 1.0'ın altındaki bir ortalama gerekli ama yeterli değil.

Prebuffering akıcılık satın alır, hızlı yanıttan çalar

Jitter sadece daha hızlı bir modelle çözülmez; buffer ile çözülür. Output stream başlamadan önce 300–500 ms ses önceden doldurulursa, geç kalan bir chunk underrun'a yol açmaz. Ancak prebuffer kullanıcıya görünürdür: bir sesli asistanda kullanıcı cümlesini bitirdikten sonra asistanın yanıt verene kadarki duraksamadır; bir ekran okuyucuda imlecin her hareketinde hissedilen gecikmedir. Kruglov, yüzeye göre ayar yapılmasını öneriyor: ara sıra bozulmayı kabul eden konuşma ürünleri için 150–250 ms, kimsenin fark etmediği anlatım ve medya için 400–800 ms, ve erişilebilirlik araçlarında kısa ifadeleri çalmadan önce tamamen sentezlemek — üç kelimelik bir ifadeni tek geçişte üretilmesi, parça parça stream edilmesinden daha az maliyetlidir.

Dikişler, quantization ve platforma özgü tuzaklar

Streaming TTS hem metni hem sesi böler ve her iki bölünme de dikiş yaratır. Cümle düzeyinde chunking bir birleşim noktasında prosodiyi kaydırır; frame düzeyinde vocoder chunking ise chunk'lar üst üste binip crossfade yapılmadıkça süreksizlik üretir. Beş ila on milisaniyelik constant-power crossfade bunun çoğunu gizler — 3 ms altı patlamalı ünsüzlerde duyulabilir tıklar bırakır, 20 ms üstü ünsüzleri bulanıklaştırır. İki başarısızlık modu öne çıkıyor: kullanıcı "örn." ya da bir Almanca bileşik kelime yazdığında metin bölücülerin bir token'ın içinden kesmesi; ve doğal duraklamaların üzerine uygulanan crossfade'ler, ki bunlar sessizlikleri daraltıp konuşmayı aceleci gösterir.

Makale devamla, quantization anlaşılırlıktan önce doğallığı bozar: bir ASR gidiş-dönüşündeki kelime hata oranı sabit kalarken ses tonu düz ve hafif vınlayıcı hale gelebilir. Kruglov bunun yerine sabit bir 50 cümlelik set üzerinde float32 referansına karşı F0 kontur kaymasını, sürekli ünlülerde spektral mesafeyi ve hem telefon hoparlörlerinde hem kulaklıklarda A/B dinlemeyi takip ediyor. Thread'ler de ödünleşim yaratıyor: dört thread chunk'ları daha hızlı bitirir ama daha çok güç çeker ve SoC'yi ısıtır; bu da RTF kaymasının arkasındaki throttling'i besler; bu yüzden on dakikalık bir oturumda iki thread artı daha büyük bir prebuffer çoğu zaman kazanır.

Platform notları somut. Android'in düşük gecikmeli AudioTrack yolu cihazın doğal örnekleme hızını bekler; dolayısıyla 24 kHz'de üretim yapıp framework'ün 48 kHz'e yeniden örneklemesine izin vermek gecikme ve istenmemiş bir filter ekler. iOS'ta düşük gecikmeli yönlendirme AVAudioSession category ve mode'a bağlıdır ve simülatörde değil donanımda test gerektirir. Gömülü Linux'ta ALSA period boyutları ve başlangıç eşikleri karttan karta değişir ve çoğu zaman varsayılan olarak yanlıştır. Büyük model ağırlıklarını memory-map etmek doğru karardır, ama soğuk başlangıçtan sonraki ilk ifade, model başlangıçta ısıtılmazsa veya hot region kilitlenmezse deadline'ları kaçıracak kadar sayfa fault'u tetikleyebilir.

Neden önemli

Phonon açık kaynakla birlikte cihaz üzeri konuşma sentezi, ekiplerin inşa edeceği değil kuracağı bir şeye dönüşüyor. Darboğaz, modelin bir telefonda çalışıp çalışamayacağından çıktının sıcak ve throttle edilmiş bir cihazda on dakika boyunca kesintisiz beslenip beslenemeyeceğine kayıyor. Yavaşlığın sadece deneyimi kötüleştirdiği request odaklı backend işinden gelen mühendislerin yeni alışkanlıklara ihtiyacı olacak: kısa ortalamalar yerine uzun oturum dağılımları, en kötü durum ve slack metrikleri, ve olay ortasında değil lansmandan önce seçilmiş bir bozulma merdiveni. Argüman yalnızca Phonon'a değil her edge ses motoruna uygulanır: bir demo ile gemiye alınabilir bir ürünü ayıran şey model kalitesi değil, zor gerçek zamanlı deadline'dır.