Missing components after install (ffmpeg.asyncio/sounddevice/Cublas64_11/Visual Studio).

[Jidis83]

Hi again @erew123 ,

(this is continued from the discussion here regarding some missing components: #245 (reply in thread) )

I had done a git pull last night and was up to date, but just got the newest batch (9-28-24) with the updated Build Tools/SDK section in the diagnostics. I do indeed get this:

Windows C++ Build tools & Windows SDK:
Windows Version: Windows 10
No Visual C++ Build Tools or Visual Studio found.

though initiating a "modify" in the Visual Studio installer shows the requirements as being present (screenshot attached).

As mentioned in the discussion, "python-ffmpeg" (to obtain ffmpeg.asyncio) and "sounddevice" were installed afterward to correct errors. If the requirements and setup are the same as before, I'd imagine I'll still get those errors on a fresh install.

I also still haven't corrected that Cublas64 error line under Network Port in the diagnostics if it's of any consequence:

NETWORK PORT:
Port Status : Port 7851 is available.
Cublas64_11 Path: Not found in any search path directories.

Aside from those two spots, I'm not currently showing anything as missing or incorrect versions in the diagnostics, but I can post the full file if you need it.

The most recent install was done line by line, using the "manual installation" instructions for the standalone version to make sure each step went through. The environment is all standard, per those instructions. I did still get my "coqui-tts not found" error during the requirements install and am looking into the wheel building components for that now.

Thanks!

[erew123]

Hi @Jidis83

I've updated the diagnostics again, which should capture other versions of the C++ build tools.

Please could you provide me a copy of your diagnostics.log file?

The CUBLAS issue, which I suspect goes along with your other issues, is that your Python cannot access the C++ build tools for compiling wheel files.

Things like Coqui-TTS and CUBLAS are downloaded from Python as WHL wheel files. The are files that are the instructions to build/compile the software for your specific system build. This is the base way Python works, so its not anything unusual, its certainly nothing specific to AllTalk. I suspect this is also the issue with the ffmpeg.asynco issue.

So, on Windows, if the C++ build tools and the Windows SDK aren't available/accessible for some reason, Python will download the WHL file for whatever, but it will fail to compile them.

Here is what I have done and what I am about to do:

1. I have used a Windows 11 virtual machine that had the build tools installed. I installed AllTalk V2 and that went through fine.

2. I am resetting that Windows 11 virtual machine, so it will be as if it was a fresh installation. Its currently mid-process right now.

3. Once it is reset to a factory fresh build of Windows, I am going to:

• Install Git
• Git clone AllTalk V2

At this stage, you will note I am NOT installing the C++ Tools and SDK. I will test the install of AllTalk, which I know will therefore fail, but I want to sift through any error messages and also I have written a script to test wheel files, so I want to see exactly the errors that generates.

Once I know that has failed, I will wipe the AllTalk installation and git clone it again. However, this time I will install Visual Studio Community edition 2022 and confirm the selection choices required to have the C++ build tools and SDK.

If that fails, I will be working on the error/issue. If it works, ill feed back.

As you can imagine this takes X hours to test and go through, so I will reply back when I reply back.

Thanks

[MoeMonsuta]

Alltalk wouldn't build/install the wheels for me without the VS 2022 SDK and MSVC both installed. Kept getting the coqui wheel build error. I also had to downgrade transformers to 4.40.0 to resolve dependency errors with coqui.

[Jidis83]

@erew123 -

Sorry for taking a bit to get back on this (and that I've split this discussion into two places).

I posted yesterday in the discussion section that I had gotten it to work, and that I suspected a messy Visual Studio install was involved somehow. I did get to dump my Windows 10 base partition image back on there last night and check things out by starting from scratch, and there was indeed a bunch of redundant C++ Redistributable junk already in my add-remove panel. That partition image was made before any specific VS, Python, or TTS related software was put on there, but there were a few audio and graphics applications installed, so I'm not sure if it came in with Windows. Either way, uninstalling all of them and installing only what you instructed, then starting the Alltalk install seemed to do the trick. I'll include a picture of the original (pre-VS install) components I already had.

I also did do the transformers downgrade Moe mentioned on the past couple runs. My install procedure was fairly simple after removing the old VS entries: 1. Visual Studio stuff 2. ESpeak 3. Git 2.46.2 64bit (at default install settings). I then did the command line procedure for the Alltalk standalone install and made my .bat files. I think I must have done the ESpeak install from one of my saved Alltalk folders, since I guess the installer won't actually come in until you pull in the whole Alltalk bundle. It might also be worth pointing out in the instructions that Alltalk itself will setup all that Python/Torch/CUDA stuff for you. On my first few installs, after seeing that separately listed in the main requirements, I was going out to find it and install it all on my own before I started the Alltalk setup, which probably didn't help. Whatever NVIDIA components were already on here were the standard drivers and stuff that Windows 10 put on.

I'll include the two diagnostic logs from before and after it was fixed, but it seemed like just those two items (VS and Cublas) were troublemakers for me.

Thanks Again!

PS (regarding that wheel error) - I thought it did a bunch of successful wheel installs during the Alltalk setup and just complained about building the one for Coqui. It also reported a version when I checked, and looked as if the actual wheel package was on here and functioning.

bad diagnostics.log
good diagnostics.log