gvne / spleeterpp

A C++ Inference library for the Spleeter project
MIT License
162 stars 33 forks source link

No tensorflow framework library in libtensorflow-cpu-windows-x86_64-1.15.0.zip #17

Closed PRPoundSix closed 4 years ago

PRPoundSix commented 4 years ago

The precompiled tensorflow library for Windows only has the tensorflow.lib and .dll. It looks like the framework dll/lib is not needed on Windows platform to successfully build projects and during runtime executions.

CMake Error at cmake/add_tensorflow.cmake:52 (message): Tensorflow could not be included

gvne commented 4 years ago

Hi @PRPoundSix thank you for your feedback. You are trying the develop branch for windows right ? I didn't check the windows compatibility yet for the latest developments. If you are not interested in the filter interface, I would suggest falling back to the latest release.

I don't have enough time to work on this at the moment but will address this as soon as possible. If you feel like it, I do accept pull requests šŸ˜„

PRPoundSix commented 4 years ago

Hi Guillaume, I tried the master branch and although the build is good. I got the following error when running the 2 stem test on Windows:

Running main() from gtest_main.cc[==========] Running 1 test from 1 test case.[----------] Global test environment set-up.[----------] 1 test from Spleeter[ RUNĀ  Ā  Ā  ] Spleeter.TwoStems2020-04-26 14:24:57.956072: I tensorflow/cc/saved_model/reader.cc:31] Reading SavedModel from:unknown file: error: C++ exception with description "bad allocation" thrown in the test body.[Ā  FAILEDĀ  ] Spleeter.TwoStems (187 ms)[----------] 1 test from Spleeter (187 ms total) [----------] Global test environment tear-down[==========] 1 test from 1 test case ran. (192 ms total)[Ā  PASSEDĀ  ] 0 tests.[Ā  FAILEDĀ  ] 1 test, listed below:[Ā  FAILEDĀ  ] Spleeter.TwoStems Ā 1 FAILED TEST C:\repos\spleeterpp\build\test\spleeter\Debug\test_spleeter.exe (process 4668) exited with code 1.Press any key to close this window . . .

I tried to fix the problem but the couldn't figure out why allocation is bad. I can successfully run the same test on the develop branch though (after some adjustments related to the issue I reported.) I may create a pull request for the develop branch later but I am both new to TensorFlow and also CMake so I need time to get familiar with both.Ā  Thanks for the shared code. On Sunday, April 26, 2020, 05:32:50 AM EDT, Guillaume Vincke notifications@github.com wrote:

Hi @PRPoundSix thank you for your feedback. You are trying the develop branch for windows right ? I didn't check the windows compatibility for windows yet for the latest developments. If you are not interested in the filter interface, I would suggest falling back to the latest release.

I don't have enough time to work on this at the moment but will address this as soon as possible. If you feel like it, I do accept pull requests šŸ˜„

ā€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

aidv commented 4 years ago

I'm getting the same error as OP.

@gvne care to point us in the right direction? What is the core issue and were could it be fixed? I'll have a look at it.

gvne commented 4 years ago

Hi there, sorry for the delay. I just pushed a fix for windows on the develop branch. However, the filter interface doesn't seem to give the right results. That being said you should be able to use the classic interface (not real time) successfully now

gvne commented 4 years ago

It seems like the problem comes from the asynchronous process of frames.
Even if each frame is computed in a separated thread, the process has to be done sequentially to avoid parallel access to the temporary buffers. I am using an std::mutex to force this. However, it seems that it std::mutex does not ensure this.
I will try using event objects as suggested here.

In the meantime, if you really want to use the filter interface, just set the extra_frame_latency to zero and you'll be fine.

gvne commented 4 years ago

Using a semaphore is better than mutex to keep the sequential aspect. I added a semaphore implementation (using std::mutex and std::condition_variable) that fixed the issue.
I also integrated the Appveyor CI to avoid that kind of issue in the future !