About Myself

---

Sumber Rujukan:

• Artikel asal dari Dev.to PHP
• Published on haqis.com

Vocalizer is a native PHP extension by Akram Zerarka that runs text-to-speech synthesis locally, with no API calls and no runtime dependencies. It embeds two inference backends — sherpa-onnx (ONNX Runtime) and audio.cpp (ggml) — and ships as a prebuilt .so binary, so there’s nothing to compile.

Here’s what the extension gives you:

• Eight model families, one API — Chatterbox, Supertonic, Piper/VITS, Pocket, Kokoro, Kitten, Matcha, and ZipVoice, auto-detected from the model directory
• Voice cloning — Chatterbox clones any voice from a 3–10 second reference WAV across 23 languages
• Anti-hallucination guard — Chatterbox output is checked for skipped text, loops, and silence, and re-synthesized with a fresh seed when it looks suspicious
• Crash isolation — models run in fork mode by default, so an engine crash is retried and reloaded instead of taking down the PHP worker
• Model cache — models load once per PHP worker (LRU eviction, vocalizer.max_models) and stay warm for subsequent requests
• Async synthesis — speakAsync() returns a job you can wait() on, with per-call timeouts
• WAV or raw PCM output — save to a file, get the WAV as a string, or grab float32 PCM

One API Across Eight Model Families

Engine::load() points at a model directory and figures out the backend from its contents. Synthesis is a single speak() call:

use Vocalizer\Engine;

$engine = Engine::load('/opt/voices/sherpa-onnx-supertonic-3-tts-int8-2026-05-11');

$res = $engine->speak('Votre commande est prête.', [
    'lang'       => 'fr',   // required for Supertonic
    'voice'      => 0,      // 0–9 preset voices
    'speed'      => 1.0,
    'timeout_ms' => 30_000,
]);

$res->save('/var/www/audio/notice.wav');
echo $res->seconds, " s in ", $res->generationMs, " ms\n";

Which model to load depends on what you’re after:

Goal	Model	Latency (CPU)
Best realism, voice cloning	Chatterbox	Slow (~20× real time)
Fast multi-language (31 languages)	Supertonic 3	Real-time
Lightweight FR/EN cloning	Pocket TTS	Fast
Fastest, one model per locale	Piper/VITS	Very fast

Voice Cloning with Chatterbox

Chatterbox covers 23 languages with a single ~7.5 GB model and clones a voice from a short reference WAV in the target language:

$engine = Engine::load('/opt/voices/chatterbox', [
    'threads' => 4,
    'opts'    => ['weight_type' => 'f16'],   // default: q8_0
]);

$res = $engine->speak('Bonjour, votre commande est prête.', [
    'lang'       => 'fr',
    'reference'  => '/opt/voices/refs/fr.wav',
    'opts'       => [
        'temperature'        => 0.6,
        'repetition_penalty' => 1.2,
        'seed'               => 42,
    ],
    'timeout_ms' => 600_000,
]);

echo $res->qualityRetries;   // guard re-syntheses (0 = first output accepted)
$res->save('/tmp/out.wav');

Autoregressive TTS models can skip text, loop, or produce silence, which is where the anti-hallucination guard comes in. Vocalizer checks every Chatterbox output against the text length and signal energy, and re-synthesizes suspicious audio with a new seed — two extra attempts by default, configurable via verify_retries. If every attempt fails, it throws a Vocalizer\Exception rather than returning corrupt audio, which makes a fallback to a faster model straightforward:

try {
    $res = $engine->speak($text, ['lang' => 'fr', 'reference' => $ref]);
} catch (\Vocalizer\Exception $e) {
    $res = Engine::load('/opt/voices/sherpa-onnx-supertonic-3-tts-int8-2026-05-11')
        ->speak($text, ['lang' => 'fr']);
}

Crash Isolation and Async

Native inference engines can crash, and a segfault inside a PHP extension normally kills the FPM worker with it. Vocalizer’s default fork isolation mode runs synthesis in a forked child process, so a crash is caught, retried (up to vocalizer.max_retries), and the model reloaded — surfacing as a Vocalizer\CrashException only when recovery fails. Chatterbox is the exception: its ggml thread pool is not fork-safe, so it always runs in direct mode.

For longer texts, speakAsync() moves synthesis off the request path:

$job = $engine->speakAsync($paragraph);
$res = $job->wait(30_000) ?? throw new RuntimeException('still running');

Behavior is tuned through php.ini directives: vocalizer.isolation (fork vs. direct), vocalizer.timeout_ms, vocalizer.max_models for the per-worker model cache, and vocalizer.max_concurrency for the async pool. One production note from the README worth repeating: model RAM is per FPM worker, and Chatterbox alone needs several GB.

Installation

Vocalizer requires Linux x86-64 (glibc ≥ 2.28) and PHP 8.4 or 8.5 NTS — Alpine/musl, ARM, and ZTS builds are not supported. The install script downloads the prebuilt extension (~44 MB) and verifies it via SHA256:

curl -fsSL https://raw.githubusercontent.com/akramzerarka/vocalizer/main/install.sh | bash

Models are downloaded separately with the bundled script:

./scripts/download-model.sh chatterbox                                    # ~7.5 GB
./scripts/download-model.sh sherpa-onnx-supertonic-3-tts-int8-2026-05-11  # ~120 MB
./scripts/download-model.sh vits-piper-en_US-amy-low                      # ~65 MB

The extension is MIT-licensed and statically links its dependencies, including sherpa-onnx (Apache-2.0), audio.cpp/ggml (MIT), ONNX Runtime (MIT), and espeak-ng (GPL-3.0 phonemization data).

You can find the full API reference, configuration details, and model catalog on GitHub.

Staff writer at Laravel News. Full stack web developer and author.

Filed in:

Source: Laravel News

3658. GCD of Odd and Even Sums
Difficulty: Easy
Topics: Mid Level, Math, Number Theory, Weekly Contest 464
You are given an integer n. Your task is to compute the GCD (greatest common divisor) of two values:

sumOdd: the sum of the smallest n positive odd numbers.

sumEven: the sum of the smallest n positive even numbers.

Return the GCD of sumOdd and sumEven.
Example 1:

Input: n = 4

Output: 4

Explanation:

Sum of the first 4 odd numbers sumOdd = 1 + 3 + 5 + 7 = 16

Sum of the first 4 even numbers sumEven = 2 + 4 + 6 + 8 = 20

Hence, GCD(sumOdd, sumEven) = GCD(16, 20) = 4.

Example 2:

Input: n = 5

Output: 5

Explanation:

Sum of the first 5 odd numbers sumOdd = 1 + 3 + 5 + 7 + 9 = 25

Sum of the first 5 even numbers sumEven = 2 + 4 + 6 + 8 + 10 = 30

Hence, GCD(sumOdd, sumEven) = GCD(25, 30) = 5.

Example 3:

Input: n = 1

Output: 1

Example 4:

Input: n = 2

Output: 2

Example 5:

Input: n = 3

Output: 3

Example 6:

Input: n = 10

Output: 10

Example 7:

Input: n = 100

Output: 100

Example 8:

Input: n = 1000

Output: 1000

Constraints:

1 <= n <= 1000 Hint: The first n odd numbers sum to n * n First n even numbers sum to n * (n + 1) gcd(n, n + 1) = 1, so the answer is n Solution: We solved the problem by recognizing that the GCD of the sum of the first n odd numbers and the sum of the first n even numbers simplifies directly to n. We identified that sumOdd = n² and sumEven = n(n+1), and since n and n+1 are consecutive integers (always coprime), their GCD is 1. Therefore, the answer is simply n, making the solution O(1) time and space complexity. Approach Identify the formulas for the sum of the first n odd and even numbers Recognize that sumOdd = n² and sumEven = n(n+1) Apply GCD properties: gcd(n², n(n+1)) = n × gcd(n, n+1) Use the fact that consecutive integers are always coprime: gcd(n, n+1) = 1 Simplify to get the answer: n × 1 = n Return n directly without computing large sums Let's implement this solution in PHP: 3658. GCD of Odd and Even Sums

Explanation:

Sum of first n odd numbers: The sequence is 1, 3, 5, …, (2n-1). The sum formula is n²

Sum of first n even numbers: The sequence is 2, 4, 6, …, 2n. The sum formula is n(n+1)

GCD calculation: We need gcd(n², n(n+1))

Factor out n: n × gcd(n, n+1) since both terms share a factor of n

Consecutive property: n and n+1 have no common factors other than 1

Final result: n × 1 = n, which matches all test cases

Optimization: No loops or array storage needed; the answer is always the input n

Complexity Analysis

Time Complexity: O(1) – constant time operation, regardless of input size

Space Complexity: O(1) – no additional memory allocation required

Contact Links
If you found this series helpful, please consider giving the repository a star on GitHub or sharing the post on your favorite social networks 😍. Your support would mean a lot to me!

If you want more helpful content like this, feel free to follow me:

LinkedIn
GitHub

---

Sumber Rujukan:

• Artikel asal dari Dev.to PHP
• Published on haqis.com

Korang pernah tak buka WordPress dashboard dan nampak widget Site Health Status tu? Dia punya bulatan hijau tu nampak menarik, lepas tu dia tulis “Baik” – tapi sebenarnya ada beberapa benda yang korang kena buat lagi. Kat bawah tu, ada tiga baris yang dia benderakan:

• Korang kena buang pemalam yang tak aktif
• Korang kena buang tema yang tak aktif
• Tapak korang ditetapkan untuk tunjuk ralat kepada pelawat

Kebanyakan orang, bila nampak benda ni, terus nak buang. Tapi saya nak cakap benda lain: ini masalah prestasi, dan cara biasa orang fix dia tak fix langsung.

Apa Sebenarnya Widget Ni Buat?

Jom kita tengok apa widget ni buat sebenarnya. Dia bukan sekadar tunjuk skor dari database. Bila korang buka dashboard, WordPress akan jalankan beberapa ujian async melalui REST API. Antara ujian tu ialah loopback test – WordPress akan call URL sendiri dan tunggu response.

Faham tak? Kat server yang share ramai-ramai, request yang nak test tapak korang tu akan bersaing dengan request yang nak tunjuk halaman yang korang tengah pandang tu. Lambatlah jawabnya.

Yang bestnya, ada satu benda yang hampir tak ada orang tahu. WordPress ada scheduled cron event nama wp_site_health_scheduled_check yang akan jalankan semua ujian tu sekali lagi di latar belakang. Setiap minggu. Setiap tapak yang korang pernah buat. Korang tak pernah nampak benda ni sebab korang tak pernah check.

Jawapan Yang Korang Akan Dapat

Bila korang google “how to remove site health widget”, inilah jawapan yang korang akan dapat:

Jawapan pertama (paling atas sekali): Pergi ke Dashboard → Screen Options → uncheck “Site Health Status”.

Masalahnya, benda ni hanya untuk satu user. Dia tulis kat user meta. Jadi bila korang uncheck tu, hanya korang je yang tak nampak. Client korang? Dia tetap nampak semua benda tu. Jadi kalau korang fikir dah selesai, sorrylah – tak selesai pun.

Jawapan kedua, orang akan bagi code macam ni:

add_action('wp_dashboard_setup', function () {
remove_meta_box('dashboard_site_health', 'dashboard', 'normal');
});

Code ni memang real. Widget tu hilang untuk semua user. Tapi tak ada apa yang berhenti. Cron tetap jalan. Ujian tetap ada. Korang cuma sorok bacaan tu je, bukan kerja sebenar. Kalau dashboard korang lambat sebelum ni, lepas guna code ni pun tetap lambat. Malah lagi teruk sebab korang fikir dah fix tapi sebenarnya tak fix.

Cara Kedua: Halaman Tools

Ada satu lagi cara yang orang suggest. Halaman Tools ni dia bukan datang dari widget, jadi dua cara tadi tak affect dia:

add_action('admin_menu', function () {
remove_submenu_page('tools.php', 'site-health.php');
}, 99);

Tapi korang kena faham: code ni buang menu item je, bukan halaman tu sendiri. Sesiapa yang taip /wp-admin/site-health.php terus kat browser, tetap boleh buka. Kalau korang nak betul-betul lock, kena guna capability, bukan sorok link.

Cara Keempat: Satu-Satunya Cara Yang Betul

Cara keempat ni ialah satu-satunya cara yang betul-betul hentikan semua semakan. Dia punya test registry dan juga cron event tu sendiri:

add_filter('site_status_tests', function ($tests) {
$tests['direct'] = [];
$tests['async'] = [];
return $tests;
});

add_action('init', function () {
$timestamp = wp_next_scheduled('wp_site_health_scheduled_check');
if ($timestamp) {
wp_unschedule_event($timestamp, 'wp_site_health_scheduled_check');
}
});

Empat hooks, empat laluan kod, satu features. Setiap panduan yang saya baca, dia cover satu je. Ada yang cover dua. Tak ada yang cover empat sekali. Dan beza antara widget tu disembunyikan dengan ujian tu dimatikan, itulah persoalan sebenar.

Apa Yang Jangan Buat

Orang selalu suggest benda ni kat forum. Jangan buat:

define('DISABLE_WP_CRON', true); // untuk stop weekly health check
// atau: unhook REST API // untuk stop async tests

Bunuh WP-Cron sebab nak senyapkan satu acara mingguan? Kena affect scheduled posts, backups, dan update checks sekali. Bunuh REST API sebab nak stop async tests? Block editor pun affected sekali. Kedua-duanya macam potong kaki sebab nak sembuhkan ruam. Kalau korang nampak benda ni kat tapak client, tanya kenapa.

Kesimpulan

Empat laluan kod yang berbeza, satu features. Widget boleh disembunyikan, tapi semakan tetap jalan di latar belakang. Kalau korang nak betul-betul hentikan Site Health, korang kena guna cara keempat: filter site_status_tests dan unschedule event cron tu.

Tapi korang kena ingat: disabled Site Health tak bermakna tapak korang sihat. Dia je yang akan bagitahu korang kalau PHP tak support, HTTPS salah config, module tak ada, atau update berhenti senyap-senyap. Matikan dia, tak ada siapa yang akan dengar benda-benda tu lagi.

---

Sumber Rujukan:

• Artikel ini diterjemahkan dari Dev.to
• Penulis asal: Lucas Fenwick
• Diterjemahkan ke Bahasa Melayu untuk haqis.com