Build failure on Mac

[danielbair]

Undefined symbols for architecture x86_64:
"_fftw_destroy_plan", referenced from:
_sonicAddPitchPeriodToSpectrogram in spectrogram.o
"_fftw_execute", referenced from:
_sonicAddPitchPeriodToSpectrogram in spectrogram.o
"_fftw_plan_dft_r2c_1d", referenced from:
_sonicAddPitchPeriodToSpectrogram in spectrogram.o
ld: symbol(s) not found for architecture x86_64

I had to run make with USE_SPECTROGRAM=0 to get it to build on Mac, but I don't know what functionality this will impact.

[dosentmatter]

Are you on the latest version of sonic? Are you possibly on the espeak-ng fork?

This repo made a fix in 2018 to link in libfftw3. The espeak repo fork is out of date and doesn't have that fix.

The build works for me after that fix. Before the fix, you can see that it failed on

gcc -Wall -Wno-unused-function -O3 -ansi -fPIC -pthread -DSONIC_SPECTROGRAM -shared -Wl,-install_name,libsonic.so.0 sonic.o spectrogram.o -o libsonic.so.0.3.0

because it was missing -lfftw3.

You can also try make CC=gcc -lfftw3. It worked for me, but the arguments to gcc might be out of order.

[waywardgeek]

Hi, Kevin. Sorry I missed your email from June! The spectrogram functionality should be disabled. I'll update the Makefile to set it this way. Espeak does not use the spectrogram feature. I only include this feature since I believe we may be able to significantly improve speech recognition using more efficient and higher quality signal analysis on the front-end. Also, Espeak should be enhanced to include the heart of the sonic algorithm for high-speed speech (> 2.0 times speedup) directly in the vocoder. I believe most commercial TTS engines have already done this. This improves the speech quality, since sonic introduces about -40 db of noise. It also reduces the CPU load which is due to sonic trying to find the best fundamental pitch estimate for every pitch epoch. Espeak's vocoder knows the pitch already. Bill

…

On Wed, Dec 23, 2020 at 3:31 PM Kevin Lau ***@***.***> wrote: Are you on the latest version of sonic? Are you possibly on the espeak fork <https://github.com/espeak-ng/sonic>? There was a fix in 2018 <0501f10> in this repo to link in libfftw3. The espeak repo fork is out of date and doesn't have that fix. The build works for me after that fix. Before the fix, you can see that it failed on gcc -Wall -Wno-unused-function -O3 -ansi -fPIC -pthread -DSONIC_SPECTROGRAM -shared -Wl,-install_name,libsonic.so.0 sonic.o spectrogram.o -o libsonic.so.0.3.0 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACVQYSU6EXVCPUWVR45D3LSWJ4WLANCNFSM4OK7IOZA> .

[dosentmatter]

Hey Bill @waywardgeek, thanks for the response and the insight on Espeak! Not a big deal, but minor correction - you actually missed Daniel's message from June. I, Kevin, only commented on this issue a few days ago.

So if Espeak-ng doesn't use the spectrogram feature, will you be disabling the spectrogram in this upstream or in the Espeak-ng fork? Do you have maintainer access to the Espeak-ng forked repo?

[dosentmatter]

Oh nevermind. I see you've made a commit to this repo. I guess somebody needs to fast-forward the Espeak-ng fork to be in sync with this upstream repo.