VOGONS


Munt Reloaded - Development

Topic actions

Reply 761 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
HunterZ wrote:

Thanks. How do I set that QT5 option? I'm not too familiar with cmake.

There are a number of ways 😀
If you use ccmake or cmake-gui, it will appear very easy. You can also type

cmake -D mt32emu-qt_WITH_QT5:BOOL=ON <path_to_sources> 

on command line. Alternatively, you can lookup the property inside the CMakeCache.txt file and edit.

Reply 762 of 965, by marooned_on_mars

User metadata
Rank Member
Rank
Member

Just got the latest commit from the git repo, and compiling the emulator libraries (mt32emu) works fine, but compiling anything else that depends on the libraries (like mt32emu_qt) ends up spewing those kinds of errors:

Master.cpp:(.text+0x25a7): undefined reference to `MT32Emu::FileStream::FileStream()'
Master.cpp:(.text+0x2614): undefined reference to `MT32Emu::FileStream::open(char const*)'
Master.cpp:(.text+0x264a): undefined reference to `MT32Emu::ROMImage::makeROMImage(MT32Emu::File*)'
Master.cpp:(.text+0x266b): undefined reference to `MT32Emu::ROMImage::getROMInfo() const'
Master.cpp:(.text+0x26cb): undefined reference to `MT32Emu::FileStream::FileStream()'
Master.cpp:(.text+0x2738): undefined reference to `MT32Emu::FileStream::open(char const*)'
Master.cpp:(.text+0x2772): undefined reference to `MT32Emu::ROMImage::makeROMImage(MT32Emu::File*)'
Master.cpp:(.text+0x2793): undefined reference to `MT32Emu::ROMImage::getROMInfo() const'
CMakeFiles/mt32emu-qt.dir/src/Master.cpp.o: In function `Master::freeROMImages(MT32Emu::ROMImage const*&, MT32Emu::ROMImage const*&)':
Master.cpp:(.text+0x2aeb): undefined reference to `MT32Emu::ROMImage::getFile() const'
Master.cpp:(.text+0x2b11): undefined reference to `MT32Emu::ROMImage::freeROMImage(MT32Emu::ROMImage const*)'
Master.cpp:(.text+0x2b4b): undefined reference to `MT32Emu::ROMImage::getFile() const'
Master.cpp:(.text+0x2b71): undefined reference to `MT32Emu::ROMImage::freeROMImage(MT32Emu::ROMImage const*)'

I'll attach the full logs of the compilation attempts and CMake.
Is this a known issue, sergm, or did I mess something up?

Also, when I did a 'make install' (with root privileges of course) after compiling the libraries, not all the include files were transferred, so I had to copy them to /usr/local/mt32emu/ manually.

Attachments

Reply 763 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

That's not an issue. The library interface is in active development. When you compile the library stand-alone, it provides new API that the other components cannot use. There are corresponding compile options if you want to play with. I have some more thoughts about that and hopefully things will stabilize in a couple of weeks.

Reply 764 of 965, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

What's the status of optimizing in the library, in general and in particular on ARM devices? If you've already mapped out some objectives, i would like to try to help.

All hail the Great Capacitor Brand Finder

Reply 765 of 965, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Sergm: with the current qt-UI code it seems that changes in the properties are not saved on OS X.
I hit properties, set something, hit save, open again and almost all changes will be reverted (the "reverb enabled" drop down seems to stick). Is this intentional or is it a bug. Tsoliman on #munt is having the same issue (or actually he mentioned it and I confirmed).

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 766 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Donimus: No, I'm not aware of this behaviour. There is nothing like that I can see on Win/Linux/FreeBSD. Probably a Qt bug. Do you use Qt5? I sometimes observe very unpleasant things in Qt5 while it's in development...

gdjacobs: Nothing changed in that area. The general code style (at least within the library) is ANSI C compatibility, so I hope there is (almost) nothing to do to port it to the ARM arch. As for the speed, I expect today's mobiles are fast enough 😀

Reply 767 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Donimus: Similar things might happen if you stop the synth and then try to change some settings. This is because the settings are stored in the synth's vars and then reloaded. If the synth is closed, some settings take no effect.

Reply 768 of 965, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Yes, I've stopped the synth, changed stuff and then started it again. Seemed like the logical thing to me 😉

And yes, QT5.5(.1I think).

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 770 of 965, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
sergm wrote:

gdjacobs: Nothing changed in that area. The general code style (at least within the library) is ANSI C compatibility, so I hope there is (almost) nothing to do to port it to the ARM arch. As for the speed, I expect today's mobiles are fast enough 😀

It's fine as far as portability. My motivation is to achieve real time emulation on a platform like the Pi2. At present, a 1ghz Cortex A7 core can almost handle it, but not quite.

My sense is that most Munt development has been oriented to accuracy at present depending on general good coding practices to keep performance requirements in check. Do you have any thoughts on more radical optimizations which could be applied?

All hail the Great Capacitor Brand Finder

Reply 771 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

When thinking about performance improvements, I guess, the best hopes should be set on using SSE-like intrinsics. However, we might not achieve a significant performance boost. The most CPU-demanding part is the sample generator in LA32WaveGenerator that emulates the LA32 chip. By the logic, the model heavily relies on the LUTs found within the chip, so the processing is quite problematic to do in parallel by a single processor core. The higher-level version of the emulation engine in LA32FloatWaveGenerator is much easier to speed up but it also significantly slower due to the use of floating-point computations (including sines and exponents).

Also, radical optimizations often end up with code harder to read, debug and maintain, which we'd like to avoid and keep the code as clear as possible. If there was a break-through optimization in the critical path, I think it would be worth to increase the code complexity. But instead, many of optimizations are compiler and/or platform specific, and therefore are not much desired.

Reply 772 of 965, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
sergm wrote:

When thinking about performance improvements, I guess, the best hopes should be set on using SSE-like intrinsics. However, we might not achieve a significant performance boost. The most CPU-demanding part is the sample generator in LA32WaveGenerator that emulates the LA32 chip. By the logic, the model heavily relies on the LUTs found within the chip, so the processing is quite problematic to do in parallel by a single processor core. The higher-level version of the emulation engine in LA32FloatWaveGenerator is much easier to speed up but it also significantly slower due to the use of floating-point computations (including sines and exponents).

Also, radical optimizations often end up with code harder to read, debug and maintain, which we'd like to avoid and keep the code as clear as possible. If there was a break-through optimization in the critical path, I think it would be worth to increase the code complexity. But instead, many of optimizations are compiler and/or platform specific, and therefore are not much desired.

Perfectly understandable. I wouldn't want a C preprocessor soup either.

I'll see how much time I've got, but I'd like to begin reading and familiarize myself with the code. You mind if I begin asking questions when the confusion sets in?

All hail the Great Capacitor Brand Finder

Reply 774 of 965, by realnc

User metadata
Rank Oldbie
Rank
Oldbie

Hand-written SSE should always be the last resort. Making sure data in hot loops always fits in the 64 byte CPU cache line and reducing data dependencies (so that the CPU core can auto-paralellize the code) is the most maintenance-friendly way of optimization.

Also, SSE code is the best way to prevent contributions since very few people understand this stuff 😜

Reply 775 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Of course. I'd add that relying entirely on the optimization performed by the compiler is even more maintenance-friendly way, and that's what we practice 😉
Unfortunately, the algorithm in LA32WaveGenerator is already not quite easy to understand in contrast to the one in LA32FloatWaveGenerator. So, if a super-optimized version ever appears, it'll most probably be in a separate module.

Reply 776 of 965, by realnc

User metadata
Rank Oldbie
Rank
Oldbie

Are you interested in patches for improving ABI compatibility in the C++ interface? I know it's more difficult to do in C++ compared to C, but I was thinking of introducing a d-pointer (aka "Pimpl idiom") and remove all private members from the headers. The exported classes would then only have public and protected members and thus any changes in the private members would not break the ABI.

Obviously doing this will break the current ABI, but that already happened now with the latest commit (making isActive() non-const).

Reply 777 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Yep, the ABI was changed in that commit, but it had been also changed before that (so, I'm bumping the major version).
I think about a bit different approach for retaining C++ ABI compatibility further on. Moreover, I assume C++ API must fully correspond to the C and plugin ones. I'll add a facade class for that shortly (well, I should actually start from this point but I'll survive 😀 ).

Reply 778 of 965, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Well, I don't know if I should slap myself on the back or in the face. The Broadcom CPU on the RPi 2 can successfully run Munt in real time, no dropped samples.
Re: Roland MT-32, CM-32L + General MIDI for $50" Building a MIDI box

CXXFLAGS used, as recommended by ARM:

-Ofast -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard
Last edited by gdjacobs on 2016-02-26, 19:58. Edited 1 time in total.

All hail the Great Capacitor Brand Finder

Reply 779 of 965, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

While working on ARM builds, mt32d and xmt32 were both found to segfault for recent git commits. I've performed a bisection analysis and believe I've located the problematic commit, but I would appreciate confirmation.

Here's the output:

961ec3ce7d06974e10e3c786d505c21fb43f35c4 is the first bad commit
commit 961ec3ce7d06974e10e3c786d505c21fb43f35c4
Author: sergm <sergm@bigmir.net>
Date: Sun Mar 6 19:42:05 2016 +0200

- Public methods of Synth made protected from calling when the synth is closed

:040000 040000 521339dbc99a20d7577d9e5f35c2f03de2b69777 24095332e6319df14428fcc65ee44e4aa6218e52 M mt32emu

Edit: I've confirmed that using the tree at the previous commit, 9939950, builds a fully functional mt32d. Using GDB determined the area of the segfault to be on the first call of getMT32Settings. My take is that the member variable opened is causing the segfault when the reverb constructor is called.

One mystery, though. I have no idea why it's doing it with mt32d and xmt32 and not mt32emu-qt.

Update: Apr. 4, 2016
Fault fixed in the latest git tree. Thanks, sergm!

All hail the Great Capacitor Brand Finder