DEV Community

orca forge
orca forge

Posted on Originally published at forge.workstyle.tech

How to Fix WSL2 Connections to Windows VOICEVOX

#wsl2 #windows #voicevox

📝 Originally published (in Japanese) at forge.workstyle.tech.

TL;DR WSL2's default NAT networking makes 127.0.0.1 inside WSL point to WSL itself, not Windows. A Windows VOICEVOX engine listening on Windows 127.0.0.1:50021 is therefore unreachable from a web app running in WSL. Try mirrored networking, expose the engine with --host 0.0.0.0 and set VOICEVOX_URL to the Windows IP, or run the engine inside WSL.

Reasons why localhost is unreachable

The connection destination of Voice Canvas is specified by the environment variable VOICEVOX_URL. The default value is http://127.0.0.1:50021. When running with Docker, http://host.docker.internal:50021 is used.

Here, it's important to note that 127.0.0.1 refers to the connecting side itself. The Windows version of VOICEVOX only listens on Windows' 127.0.0.1:50021. On the other hand, the app is running inside WSL.

WSL's default network is NAT. Therefore, even if a web server inside WSL connects to 127.0.0.1:50021, the connection destination is WSL itself, not Windows. Even if VOICEVOX is started on Windows, it will not reach the listening destination.

On Windows, Voice Canvas is run inside WSL2's Ubuntu. This is because the startup script is written in bash and the location of venv assumes a Linux/Mac format. The README notes that operation has been confirmed on Windows 11 and WSL2 (Ubuntu 22.04).

There are mainly three ways to fix the connection destination issue.

Solution 1: Setting WSL to Mirror Mode

This is a method that can be tried without changing the code. Write the following settings to %USERPROFILE%\.wslconfig:

[wsl2]
networkingMode=mirrored
Enter fullscreen mode Exit fullscreen mode

Then, run the following in PowerShell and restart WSL:

wsl --shutdown
Enter fullscreen mode Exit fullscreen mode

With this method, you can continue to use the default connection destination of Voice Canvas, http://127.0.0.1:50021.

There is a precaution to note. wsl --shutdown will stop all work inside WSL. Please save any work you are doing in servers or terminals before running it.

This method is suitable when you do not want to change the connection destination of the app. Since the procedure to stop and restart WSL is necessary, choose the timing carefully when you have ongoing work.

Solution 2: Start VOICEVOX in a Connectable State from WSL

Start the Windows version of the VOICEVOX engine with --host 0.0.0.0. Then, specify the Windows IP address in VOICEVOX_URL. If using WSL's default gateway, you can find the IP address within WSL using the following command:

ip route | awk '/default/ {print $3}'
Enter fullscreen mode Exit fullscreen mode

For example, if the command returns 172.19.128.1, set the connection target as follows:

VOICEVOX_URL=http://172.19.128.1:50021
Enter fullscreen mode Exit fullscreen mode

This IP is just an example. Be sure to verify the actual value by running the command within WSL. You may also need to allow the connection through the Windows firewall.

This method is suitable when you want to explicitly specify the connection target without using mirror mode. You'll need to configure both the engine's startup method and the app's connection target, as well as verify the Windows IP address.

Solution 3: Run the engine inside WSL

This method involves running the VOICEVOX engine inside WSL instead of Windows. You can either use the Linux version or run voicevox/voicevox_engine using Docker.

If both the app and the engine are within the same WSL environment, you can configure the connection to 127.0.0.1. If you are running Voice Canvas via Docker, use http://host.docker.internal:50021 as the connection address.

If you prefer to use the Windows version of VOICEVOX as-is, please choose a different solution. However, if you are able to run the engine on the WSL side as well, this is a viable option to consider.

Providing WSL Guidance from the App

When the connection cannot be established, displaying only "VOICEVOX not found" to the user makes it difficult to identify the cause. In Voice Canvas, the app determines whether it is running on WSL or not and provides guidance tailored to the environment.

You can determine if it's WSL by checking if microsoft is included in the Linux environment's /proc/version. When the connection fails, a 503 response with a WSL indicator is attached, and WSL-specific guidance is displayed on the screen.

The type of failure is also distinguished. The location to check differs between when there is no response and when the connection is refused. By conveying the difference in errors to the user, it becomes easier to verify the connection destination or engine waiting settings.

Another Pitfall: Node.js on the Windows Side

Sometimes, the Windows-side Node.js can end up mixed into the WSL PATH. In environments where you use tools like nvm4w, running node inside WSL might accidentally invoke the Windows version instead of the Linux one.

If you're using Node.js 20 or later, install the Linux version inside WSL. Use the following command to check which executable is being used:

which node
Enter fullscreen mode Exit fullscreen mode

Verify that the displayed path points to a location within WSL. If issues persist at app startup even after correcting VOICEVOX's connection target, also verify the Node.js execution environment.

Choosing an Approach

  • Use mirror mode if you want to test without changing the connection target.
  • If you continue using the Windows version of the engine and want to explicitly specify the connection target, set --host 0.0.0.0 and the IP address on the Windows side.
  • If you can run the engine within WSL, use the Linux version or the Docker version.

Regardless of the method, first verify where the engine is listening for connections. The Voice Canvas README also lists the required packages for launching on WSL.

sudo apt install -y git build-essential python3.10-venv python3.10-dev
Enter fullscreen mode Exit fullscreen mode

python3.10-venv is used for virtual environments. build-essential and python3.10-dev are required to build pyworld. Pre-built packages for pyworld are not available for Python 3.10, so it must be built from source.

If you plan to use a GPU, configuration is not limited to the WSL side. The GPU in WSL runs using the NVIDIA driver on the Windows side. Since torch 2.4.0 is built for CUDA 12.1, you need a driver version that supports CUDA 12.1 or higher. With an older driver, such as 522.06 (which supports up to CUDA 11.8), you will see the message "NVIDIA driver on your system is too old" and the system will fall back to CPU processing.

Key takeaways

  • Use mirrored networking when you want to keep the default VOICEVOX_URL.
  • For the Windows engine, start it with --host 0.0.0.0 and set VOICEVOX_URL to the Windows IP found from WSL.
  • If the engine can run in WSL, use the Linux or Docker version; the app and engine can then share 127.0.0.1.
  • First check where the engine is listening. If startup problems remain, check which Node.js executable which node selects.

Related Articles

Repository: Voice Canvas

Top comments (0)