Voice sounds like "donald-duck"

[mkiol]

Firstly I would like to thank to all RHVoice team for your work. The quality of voice synthesis is truly amazing. Moreover i love the code. It is well written and elegant C++ which warms my hart even more ❤️ .

I'm using RHVoice as a library in the app I'm developing. I faced following problem on Linux:

• RHVoice library generates funny "donald-duck" like voice instead proper one. Sample: 16877845491856538198.webm.
• Surprisingly, the problem does not occur when OS language is set to 'en_US' but occurs when lang is for instance 'pl_PL'.

Luckily, I've managed to find the cause 😌. It appears that function which reads configuration for HTS engine uses atof and atof is locale-dependent. In my case (locale 'pl_PL') proper decimal separator is comma (not point) , therefore ALPHA parameter for the engine was always 0 because atof wasn't able to properly parse "ALPHA=0.466".

I'm compiling RHVoice libs from sources, so I fixed the problem using simple wrapper around atof. It works well in my case.

static double locale_independent_atof(const char *str) {
    const char *old_locale = setlocale(LC_NUMERIC, "C");
    double value = atof(str);
    setlocale(LC_NUMERIC, old_locale);
    return value;
}

Maybe someone else faced the similar problem and this will help save the day of debugging.

[zstanecic]

Hi, Here the sampling rate can be the culprit, too. Best, Zvonimir From: Mkiol ***@***.***> Sent: Friday, May 19, 2023 2:44 PM To: RHVoice/RHVoice ***@***.***> Cc: Subscribed ***@***.***> Subject: [RHVoice/RHVoice] Voice sounds like "donald-duck" (Issue #740) Firstly I would like to thank to all RHVoice team for your work. The quality of voice synthesis is truly amazing. Moreover i love the code. It is well written and elegant C++ which warms my hart even more ❤️ . I'm using RHVoice as a library in the app I'm developing. I faced following problem on Linux: * RHVoice library generates funny "donald-duck" like voice instead proper one. Sample: 16877845491856538198.webm <https://github.com/RHVoice/RHVoice/assets/1420902/76983033-f136-4b55-ae0c-ac759f50e6cf> . * Surprisingly, the problem does not occur when OS language is set to 'en_US' but occurs when lang is for instance 'pl_PL'. Luckily, I've managed to find the cause 😌. It appears that function which reads configuration for HTS engine uses <https://github.com/RHVoice/RHVoice/blob/c1e897d90c663613086398cd019882e907d02314/src/hts_engine/HTS_engine.c#L169> atof and atof is locale-dependent. In my case (locale 'pl_PL') proper decimal separator is comma (not point) , therefore ALPHA parameter for the engine was always 0 because atof wasn't able to properly parse "ALPHA=0.466". I'm compiling RHVoice libs from sources, so I fixed the problem using simple wrapper around atof. It works well in my case. static double locale_independent_atof(const char *str) { const char *old_locale = setlocale(LC_NUMERIC, "C"); double value = atof(str); setlocale(LC_NUMERIC, old_locale); return 0; } Maybe someone else faced the similar problem and this will help save the day of debugging. — Reply to this email directly, view it on GitHub <#740> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVCDEZHXKMQHBWBE4R6TUTXG5TIJANCNFSM6AAAAAAYHXRL6E> . You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/ACVCDEYI26RPYDVLNB4O3CDXG5TIJA5CNFSM6AAAAAAYHXRL6GWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHGMWR76A.gif> Message ID: ***@***.*** ***@***.***> >

[mkiol]

Here the sampling rate can be the culprit, too.

Believe me, I've tried everything including changing the sampling rate for all possible values. For sure it was a atof. Literally, I spent one day with debugger comparing every line of code for OK and NOK case!

Positive side, I'm now GDB expert 😄.