furnace

furnace copied to clipboard

Finally got a setup that's functional enough for me to test this stuff. I figured a tracking issue would help with keeping an overview of all the various things that need fixing. I'm gonna add problems as individual comments as they arise.

• For audio problems, I'll attach recordings done via ./furnace --console --output.
• Anything that needs graphics is currently not doable due to https://github.com/tildearrow/furnace/issues/649#issuecomment-1224321755, thus my testing is limited to furnace --console.

---

• [ ] Compilation error: dereferencing type-punned pointer will break strict-aliasing rule [-Werror=strict-aliasing]
• [ ] Segfault on graphical start-up
• [ ] Chip-specific broken audio:
  • [ ] TSU
  • [x] OPN2 (FM6 PCM)
  • [x] Amiga
  • [x] SegaPCM
  • [ ] SAA1099
  • [x] NES (DPCM)

Compilation error: dereferencing type-punned pointer will break strict-aliasing rule [-Werror=strict-aliasing]

[ 36%] Building CXX object CMakeFiles/furnace.dir/src/engine/safeReader.cpp.o
/home/puna/devel/furnace/src/engine/safeReader.cpp: In member function 'float SafeReader::readF()':
/home/puna/devel/furnace/src/engine/safeReader.cpp:139:12: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  139 |   return *((float*)(&ret));
      |           ~^~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [CMakeFiles/furnace.dir/build.make:1182: CMakeFiles/furnace.dir/src/engine/safeReader.cpp.o] Error 1

Segfault on graphical start-up

This happens when trying to run furnace (built with BUILD_GUI=ON) without --console. The window decoration from the window manager briefly flashes up before the application crashes with the following backtraces:

Backward-cpp:

Stack trace (most recent call last):
#8    Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in 
#7    Object "/usr/lib/libc.so.6", at 0x3ff95fe31ec3, in __libc_start_main
#6    Object "/usr/lib/libc.so.6", at 0x3ff95fe31cdb, in 
#5    Object "./build/furnace", at 0x5e46b8dbf3, in main
#4    Object "./build/furnace", at 0x5e46ed04ef, in FurnaceGUI::init()
#3    Object "./build/furnace", at 0x5e46dad1af, in ImFontAtlas::Build()
#2    Object "./build/furnace", at 0x5e46dafe07, in 
#1    Object "./build/furnace", at 0x5e46da0427, in 
#0    Object "./build/furnace", at 0x5e46d9ab48, in 
Segmentation fault (Address not mapped to object [0x3ffa03a8f013])
Segmentation fault

GDB:

Thread 1 "furnace" received signal SIGSEGV, Segmentation fault.
stbtt__find_table (data=data@entry=0x3fff9ba8f010 "", fontstart=fontstart@entry=4294967295, tag=tag@entry=0x100411660 "cmap") at /home/puna/devel/furnace/extern/imgui_patched/imstb_truetype.h:1313
1313	   stbtt_int32 num_tables = ttUSHORT(data+fontstart+4);
(gdb) bt
#0  stbtt__find_table (data=data@entry=0x3fff9ba8f010 "", fontstart=fontstart@entry=4294967295, 
    tag=tag@entry=0x100411660 "cmap") at /home/puna/devel/furnace/extern/imgui_patched/imstb_truetype.h:1313
#1  0x00000001002b0428 in stbtt_InitFont_internal (info=info@entry=0x101838480, data=0x3fff9ba8f010 "", fontstart=-1)
    at /home/puna/devel/furnace/extern/imgui_patched/imstb_truetype.h:1397
#2  0x00000001002bfe08 in stbtt_InitFont (offset=<optimized out>, data=<optimized out>, info=0x101838480)
    at /home/puna/devel/furnace/extern/imgui_patched/imstb_truetype.h:4962
#3  ImFontAtlasBuildWithStbTruetype (atlas=0x10182d830) at /home/puna/devel/furnace/extern/imgui_patched/imgui_draw.cpp:2441
#4  0x00000001002bd1b0 in ImFontAtlas::Build (this=0x10182d830)
    at /home/puna/devel/furnace/extern/imgui_patched/imgui_draw.cpp:2342
#5  0x00000001003e04f0 in FurnaceGUI::init (this=0x100c25168 <g>) at /home/puna/devel/furnace/src/gui/gui.cpp:4571
#6  0x000000010009dbf4 in main (argc=<optimized out>, argv=0x3ffffffff448) at /home/puna/devel/furnace/src/main.cpp:541

---

Update: https://github.com/tildearrow/furnace/issues/649#issuecomment-1253911550

The problem is that the encoding of the embedded fonts uses a multi-byte int type that get reinterpreted as chars, which is affected by endianness and messes up the font loading code in ImGui. (possibly upstream bug?) The workaround is to use the -base85 option when converting the fonts and ImFontAtlas::AddFontFromMemoryCompressedBase85TTF when loading them, but old MSVC may reject some of the larger fonts due to string literal size limitations.

Broken Audio: TSU

• atmosphere: x86_64 vs powerpc64 TSU sounds completely wrong here.

• Silver Surfer - Stage Music 1 and su_memory are equally messed up, examples omitted for brevity.

---

Update: https://github.com/tildearrow/furnace/issues/649#issuecomment-1316673932

Broken Audio: OPN2 (FM6 PCM)

Fixed as of https://github.com/tildearrow/furnace/issues/649#issuecomment-1257311277.

Old report here

• Carnage: x86_64 vs powerpc64 Just loud noise. Here's a screenshot of the first sample on ppc64.

• CorridorsOfTimeRMX: x86_64 vs powerpc64 Also wrong here, though they would sound pretty good in other styles of music :smile:

But

• Checknobankh: x86_64 vs powerpc64 Sounds fine to me?

Broken Audio: Amiga

Fixed as of https://github.com/tildearrow/furnace/issues/649#issuecomment-1257311277.

Old report here

• GranularFurn: x86_64 vs powerpc64 Like TV static.

• m7 vibe: x86_64 vs powerpc64 More TV static.

But

• bruno time: x86_64 vs powerpc64 Sounds fine to me?

• HoldOn: x86_64 vs powerpc64 Also fine?

---

~~An observation: Both broken examples have Stereo separation of the Amiga set to 0, while both working ones have it at non-zero values (31 & 26 respectively). I don't know if that is significant or not.~~ Seems coincidental. I tried setting it to 0 and playing both modules back on the machine, they still worked.

Broken Audio: SegaPCM

Fixed as of https://github.com/tildearrow/furnace/issues/649#issuecomment-1257311277.

Old report here

• Ice_Wind_OPMSPCM: x86_64 vs powerpc64 Seemingly no sound output from SegaPCM.

• Jet_Pack_Adventure_GBAesque: x86_64 vs powerpc64 Loud noise.

• Tubelectric_Fictional_Arcade behaves like Ice_Wind_OPMSPCM, examples omitted for brevity.

• the_machines_are_socialising behaves like Jet_Pack_Adventure_GBAesque, examples omitted for brevity.

Broken Audio: SAA1099

• ridiculous_game: x86_64 vs powerpc64

• super_fantasy_zone_mango: x86_64 vs powerpc64

Cacophonies of noise. SAA1099 seems way too loud. Here is a screenshot with ridiculous game loaded, instrument 03 selected and playing & holding a single C3. As you can see from the oscilloscope & volume indicator, it's very wrong.

---

Update: https://github.com/tildearrow/furnace/issues/649#issuecomment-1316673932

Broken Audio: NES (DPCM)

Fixed as of https://github.com/tildearrow/furnace/issues/649#issuecomment-1257311277.

Old report here

• spamton: x86_64 vs powerpc64 DPCM audio starts playing ~0:19, just loud noise on ppc64. Screenshots of the first sample in furnace: Obviously not correct.

But:

• carve_your_own_path: x86_64 vs powerpc64 Sounds completely fine to me. Sample also looks just like it does on x86.

---

Similar to Amiga: Seems to either be TV static or completely fine. Or maybe wrong endianness somewhere has less of an effect that I'd imagine.

Thank you for the big-endian analysis! Regarding the GUI crash issue, it could be that stb only supports little-endian systems... I think I should try using the FreeType backend instead (which may fix #624 as well or not)...

Sound Unit being broken is expected because it's a little-endian chip and the way it is currently implemented expects the host to be so...

Regarding the GUI crash issue, it could be that stb only supports little-endian systems...

I did some digging, and we're already failing at correctly determining the font's decompressed size in stb_decompress_length: 408355328 on the ppc, 153368 on x86. However, I don't think this is a problem in stb:

• stb_decompress_length takes a unsigned char *, which by itself wouldn't have any endianness problems
• ImFontAtlas::AddFontFromMemoryCompressedTTF takes a void * for compressed_ttf_data, so it passes on whatever you give it
• FurnaceGUI::applyUISettings gives it builtinFont[settings.mainFont], which evaluates to font_plexSans_compressed_data, which is… an unsigned int * and thus affected by endianness when reinterpreted via casting!

So the problem is that all the compiled-in fonts are encoded via ints rather than chars, causing the (input[8] << 24) + (input[9] << 16) + (input[10] << 8) + input[11] in stb_decompress_length to see 0x18 0x57 0x02 0x00 instead of the intended 0x00 0x02 0x57 0x18. I imagine this flipped-around byte order also causes other sorts of problems in the rest of the code that tries to read it.

I think compressing the fonts with the -base85 option might help because that uses unsigned char * instead. Base85 decoding in ImGui, from a quick glance, might be okay and has received a big-endian fix in the past, but this line in imgui's encoding tool looks suspicious.

(Note that even the comments in ImGui's compression tool mention endianness-dependent results when using number constants > 8-bit instead of a Base85 string / array of bytes, although I think the documentation/comments aren't great at highlighting why you might want to opt-in to using Base85 encoding, and sometimes abit vague regarding what the default is & how to use Base85-encoded fonts.)

Reencoding the fonts as Base85 on x86, copying them over to ppc and using ImFontAtlas::AddFontFromMemoryCompressedBase85TTF for loading them might be worth a test at least, though I'll have to try that another time.

Confirming that using Base85 encoding (doing binary_to_compressed_c -base85 -nostatic font.ttf font_symbol > font_symbol.cpp for all compiled-in fonts) would fix graphical startup.

Missing symbols I assume are due to me using freshly downloaded ttfs from the interwebs instead of the exact ones you used, also happens on x86. (compare/fonts/base85-encoding, compressed sizes are redundant with this but kept for smaller diff)

After a17f499384201e1674e556e8576d9841aa78c56d (currently on 89ece07), the following platforms are fixed (sounds fine, matching sha256sums between x86_64 and powerpc64 renders):

• Amiga
• NES (DPCM)
• OPN2 (FM6 PCM)
• SegaPCM

Tried to improve SAA1099 and Sound Unit. Please test.

Getting better but not quite there yet.

SAA1099

• ridiculous_game: x86_64 vs powerpc64

TSU

Doesn't compile, see https://github.com/tildearrow/furnace/commit/c14e24688f63f3f6e8e1118778c6c7b68516a1bc#r90076253. With fix applied:

• atmosphere: x86_64 vs powerpc64

SAA1099 seems to be good! ...but now AY8930 broke...

SAA1099 seems to be good!

Panning seems inverted to me? Here's the SAA1099 part of the song isolated, ~37s in.

https://user-images.githubusercontent.com/23431373/202160817-d3babe29-e9db-439c-b4a9-51df4bf88dd4.mp4

x86_64 vs powerpc64

I pushed a commit which should fix Sound Unit for good.

Compilation error: dereferencing type-punned pointer will break strict-aliasing rule [-Werror=strict-aliasing]

[ 36%] Building CXX object CMakeFiles/furnace.dir/src/engine/safeReader.cpp.o
/home/puna/devel/furnace/src/engine/safeReader.cpp: In member function 'float SafeReader::readF()':
/home/puna/devel/furnace/src/engine/safeReader.cpp:139:12: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  139 |   return *((float*)(&ret));
      |           ~^~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [CMakeFiles/furnace.dir/build.make:1182: CMakeFiles/furnace.dir/src/engine/safeReader.cpp.o] Error 1

Pushed another commit to hopefully fix this as well.

Compilation fixed, checked that one off the list.

---

...but now AY8930 broke...

AY-3-8910 and AY-3-8930.

• AY-3-8910_Jam: x86_64-linux vs powerpc64-linux
• Red_Planet: x86_64-linux vs powerpc64-linux

Also when it's used in the YM2203/YM2608.

• Blue_Nebula: x86_64-linux vs powerpc64-linux

---

I pushed a commit which should fix Sound Unit for good.

Cannot confirm.

• thick bass test: x86_64-linux vs powerpc64-linux

---

Panning seems inverted to me? Here's the SAA1099 part of the song isolated

This is also still happening, new recordings in case it matters:

• ridiculous_game (SAA1099 solo'd): x86_64-linux vs powerpc64-linux

Sound Unit now truly fixed.

SAA1099 panning issue possibly fixed.

From a quick listen, TSU sounds fixed to me now.

thick_bass_test.powerpc64-linux.wav

I see what's going on. It appears that on big-endian, a bit array is in the reverse order as well...

Please test AY/AY8930 and SAA1099. Test GUI as well - I added a workaround.

AY and SAA working properly now. GUI launches as well.

All done (so far) - issue is closing. Onwards to 0.6!