-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add MSVC support for GigPlayer #6595
Conversation
cmake/modules/FindGig.cmake
Outdated
if(libgig_FOUND) | ||
get_target_property(libgig_Location libgig::libgig LOCATION) | ||
get_target_property(libgig_Include_Path libgig::libgig INTERFACE_INCLUDE_DIRECTORIES) | ||
get_filename_component(libgig_Path LibGig_Location PATH) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than using individual variables extracted from the imported target, it's more idiomatic modern CMake to link to the target directly. In the pkg-config case, consider instead assembling the information read from pkg-config into an imported target named the same as that from vcpkg.
(Feel free to consider this out of scope, since the current style is the one in use prior to this PR, but I've taken the opportunity to switch over to targets when doing similar PRs in the past.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is beyond what I know of CMake, but if you have a reference of another done then I can work on converting it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FindPortaudio.cmake
is probably closest to what you're trying to do, but FindLame.cmake
and FindSTK.cmake
are quite similar too. FindFluidSynth.cmake
and FindSDL2.cmake
are a bit more complex, but should serve as further examples.
@Veratil BTW, are you going to submit a PR against the vcpkg upstream? |
I'm not too familiar with vcpkg so I was hoping Dom could check out the branch and see if there's anything I missed. You're welcome to do it, too, though. I see vcpkg has a very specific way to add new ports, so I'd have to go through and fix whatever I didn't do properly. |
I'm not sure if I'm doing things correctly, but here's what I'm doing: https://github.com/PhysSong/vcpkg/tree/libgig |
unsigned long size = sample.sample->Read( buffer, samples ) * sample.sample->FrameSize; | ||
std::memset( (int8_t*) buffer + size, 0, allocationsize - size ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unsigned long size = sample.sample->Read( buffer, samples ) * sample.sample->FrameSize; | |
std::memset( (int8_t*) buffer + size, 0, allocationsize - size ); | |
const auto size = sample.sample->Read(buffer, samples) * sample.sample->FrameSize; | |
std::memset(buffer + size, 0, allocationsize - size); |
Perhaps this can be written a bit better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a lot of changes that should happen here in GigPlayer, but I decided to leave this as a minimum viable PR to get it to build on Windows. Definitely something that should be updated in a followup.
What's the state of this pr now? Is the gig port going to vcpkg or would it be fine enough to submodule it and get it merged, then followed up by a submodule removal pr when libgig becomes available on vcpkg. |
libgig still needs to be PR'd to vcpkg, then this could be merged. I just haven't done it. |
Is it ok if I open the pr before you? |
Feel free to. |
PR opened upstream here |
sampleFrame convertBuf[frames]; | ||
#else | ||
const auto convertBuf = static_cast<sampleFrame*>(_alloca(frames * sizeof(sampleFrame))); | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try to avoid calling _alloca
within a loop - it can easily lead to a stack overflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What should we use instead? I don't recall where I got this from but I do remember MSVC did not like convertBuf
as it's defined above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lift the variable out of the loop if possible - it should be fine to reuse the same buffer for each iteration. There's another instance in this file where the array size is computed inside the loop - in this case, see if it's possible to compute an upper bound for the size.
Eventually, we should get rid of compiler-specific, non-standard stuff like this and preallocate buffers on the heap. However, that's a fairly significant change that's out of scope here, and needs to be applied elsewhere in the codebase too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is another simple solution: move the loop body to another function to make sure the memory allocated by _alloca
is deallocated at the end of every iteration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found an even simpler solution for now (It's an ugly hack which should be replaced asap but for the current use case, didn't find anything simpler).
We can add
#ifdef _MSC_VER
_freea(convertBuf)
#endif
Just before closing the loop. That way, it'll deallocate the convertBuf
and avoid the memory leak. Tbh we should be rewriting this part but it's beyond the scope.
@@ -0,0 +1,35 @@ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a blank line here. Also, do you want to add a copyright notice to this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't sure what copyright to put since it's nearly a direct copy of some others.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm no lawyer, but I imagine something like this should be fine:
# Copyright (c) <year> <name>
# Based on <file>, copyright (c) <name> <year>
#
# Redistribution and use is allowed according to the terms of the New BSD license.
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
Besides, if you, the author, are not sure about the copyright, some random person in the future wanting to use this in their project is going to have absolutely no clue.
Forgot to mention, it would be good to add libgig to the ci dependency list once vcpkg merges the port. |
After some testing, I found that libgig crashes on release builds but not on debug builds. I have such instances of crashes with other places too but might as well mention this here because i could get lmms to crash by opening a gig file on gig player using a release build. edit : saw dom's comment on a line. Is it related? |
Short of addressing the comment and seeing if that fixes it, there's no way to tell unless you can get a backtrace. If you need help with this, ask in |
happened to reproduce the crash again and the prompt i'm getting is steps to reproduce:
|
Update: merged.
Not related. Need to investigate the crash again. Inviting @superpaik for testing. |
This is indeed unrelated, and a result of trying to activate too many notes at the same time afaict. The note start will queue and get dropped then the note end will process and trigger this. |
It builds and works ok. What I did to build it:
|
Thanks for testing.
No need anymore, just use standard vcpkg, be sure to Also,i noticed a crash while using libgig. Can you reproduce it? |
Retested with standard vcpkg, and everything Ok.
Yes, it crashes when deleting the track. But I don't think it's related to gigplayer, because it crashes also if you do the same with the tripleOsc. |
int8_t buffer[allocationsize]; | ||
#else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also add _freea(buffer)
within the ifdef i posted in the other review comment.
Edit : GitHub view messed up I'm referring to the line below what's shown.
I have a patch here which I did. You can apply this here if you are fine with this. |
Closing in favor of #7162 |
vcpkg port for testing can be found here: https://github.com/Veratil/vcpkg/tree/add-port-libgig