noisy output

[claire-kabdebon]

Hello,
I just installed Mbrola on my MacOS 64bit.
I was able to compile the project - with a little workaround though: I commented the definition of the swab function in common.h and common.c . (I'm pretty ignorant of the compilation process, so I'm not sure this was a good idea..).
It did compile OK, no errors, but some warnings:
-optimization level '-O6' is not supported; using '-O3' instead
-argument unused during compilation: '-ansi')
I thereafter downloaded a voice database (fr4), pasted it in the bin directory, and from the bin directory typed the following command:
./mbrola fr4/fr4 fr4/TEST/bonjour.pho bonjour.wav

I do get a bonjour.wav output file, no warning, no error, but when I play it, it's all noise (modulated)...
Did I forgot something in the way? Or is the voice database not properly installed?

Thank you !

[valdisvi]

In general, it seems only MacOS related problem. In issue #3 some ideas for compilation settings are provided, but no success is reported.

[BenTalagan]

Hi, I'd be interested in making this work under MacOS too. I've observed the same "noisy output" behavior in the same conditions. To make mbrola compile, I had to get rid of the optional definition of the already defined swab function, in common.h, like this (removed some ifdef) :

#if defined(TARGET_OS_VMS) || defined(TARGET_OS_BEOS) 
void swab( const char *from, char *to, int nbytes);
#endif

What would be a good way to debug this - probably by comparing some output/debug print/etc with any another platform where it's working, to narrow down the problem?

[peter-grajcar]

Hi, I have recently encountered the same issue but I have managed to get it work. I replaced the swab function with memcpy in the following way:

Misc/common.h
@@ -70,12 +70,16 @@

-#if defined(TARGET_OS_VMS) || defined(TARGET_OS_BEOS) || defined(TARGET_OS_MAC) || defined(__STRICT_ANSI__)
-#if ! defined(__MINGW64__) && ! defined(__MINGW32__)
+#if defined(TARGET_OS_VMS) || defined(TARGET_OS_BEOS) || defined(__STRICT_ANSI__)
+#if ! defined(__MINGW64__) && ! defined(__MINGW32__) && ! defined(TARGET_OS_MAC)
 void swab( const char *from, char *to, int nbytes);
 #endif
 #endif

+#if defined(TARGET_OS_MAC)
+#define swab(a, b, c) memcpy(a, b, c)
+#endif

Misc/common.c
@@ -28,7 +28,7 @@

-#if defined(TARGET_OS_VMS) || defined(TARGET_OS_BEOS) || defined(TARGET_OS_MAC)
+#if defined(TARGET_OS_VMS) || defined(TARGET_OS_BEOS)

[valdisvi]

@peter-grajcar, thanks for description. I updated project according to it: 19f31eb

[BenTalagan]

I have compiled the latest commit under MacOS 11.3 (after uncommenting -DTARGET_OS_MAC in the makefile). I confirm it compiles and fixes the problem (at least for me). Thanks a lot for having found the culprit!

[peter-grajcar]

I would like to add that this fix is a bit hacky (redefining swab as memcpy). It was intended to be minimalistic. I think it might be a good idea to look at this issue in more depth and figure out why is the swab function called in the first place. Because apparently the bytes need not to be reordered.

[BenTalagan]

I do agree ; it looks like the current implementation is meant not to rely on endianness detection, but uses an explicit flag in the makefile to indicate the endianness (CFLAGS += -DLITTLE_ENDIAN). IIRC, old PPC macs were big endian architectures so this issue might indicate something's left in the source code relying on the wrong/historical endianess (?).

[BenTalagan]

After investigation, it seems that when debugging the preprocessor states in Misc/common.h on macos, both LITTLE_ENDIAN and BIG_ENDIAN variables are defined. If I understand correctly what's done here, my guess is that one condition is missing here :

MBROLA/Misc/common.h

Lines 94 to 99 in 19f31eb

	/* Intel based machine ? */
	#if defined(__i386) || defined(_M_X86) || defined(TARGET_OS_VMS)
	#undef BIG_ENDIAN
	#undef LITTLE_ENDIAN
	# define LITTLE_ENDIAN
	#endif

Adding the condition || defined(TARGET_OS_MAC) at the end of line 95 solves the problem for me too (instead of redefining the swab function).

Having both LITTLE_ENDIAN and BIG_ENDIAN defined probably creates interferences, I propose to add something like this at the end of the "endianness handling" section to prevent this from happening again :

#if defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)
#error "Both LITTLE_ENDIAN and BIG_ENDIAN are defined and this should not happen."
#endif

[BenTalagan]

Added a PR (#27) regarding my precedent comment.