VALL-E X on Docker via WSL for Voice Cloning

I have previously installed VALL-E X for voice cloning on my own PC in a Python virtual environment.

A certain site

VALL-E X Installation with Python Virtual Environments & Docker for CUDA Explore the process of installing VALL-E X for multilingual text-to-speech synthesis and speech cloning while detailing how to configure CUDA using both a Pytho…

Today we will do this using Docker; we will install Docker on WSL.

WSL (Windows Subsystem for Linux) is a feature that allows you to run a Linux operating system directly on Windows 10 or Windows 11. This enables Windows users to use Linux command line tools, utilities, and applications within the Windows environment. Keep the following points in mind:

No dual-booting required:

With WSL, there is no need to reboot your PC to install Linux as a separate operating system; Linux runs directly within Windows.

Access to developer tools:

WSL is particularly useful for developers, as it allows them to use programming languages, tools, and applications that run in a Linux environment on Windows.

Easy setup:

Since WSL is built into Windows, setup is relatively straightforward. Simply download a Linux distribution (e.g., Ubuntu, Debian, etc.) from the Microsoft Store, and you’re up and running in just a few steps.

File system sharing:

The file system can be shared between Windows and Linux, enabling you to access and work with the same files in both environments.

Performance:

WSL provides high performance on Windows. In particular, WSL 2 offers significantly improved performance because the Linux kernel runs directly on Windows.

In short, WSL is a powerful tool that allows Windows users to benefit from Linux functionality. This makes it easy to work in both Windows and Linux environments, which is especially useful for developers.

Docker can be used to solve project dependency issues and provide a more consistent development and deployment environment. The main benefits are:

Environment consistency and predictability:

Docker provides an isolated environment called a “container.” This ensures that the environment you develop in runs exactly the same on another machine, reducing issues caused by dependencies or specific library versions.

Independence from the host system:

A Docker container is isolated from the host system. This allows applications to run independent of the host’s CUDA version and other system-specific settings, resulting in better compatibility among users with different environments and CUDA versions.

Simplified setup:

Users simply install Docker and launch the container to obtain an environment with all necessary dependencies and settings. This eliminates the need for complex setup procedures.

Consistency between development and production environments:

Docker minimizes problems caused by differences between development and production environments by using the same container images for development, testing, and production.

Scalability and ease of management:

Docker minimizes problems caused by differences between development and production environments by using the same container images for development, testing, and production.

With Docker, developers can focus on their projects in a more consistent environment without worrying about specific system configurations and dependencies. Users can also easily set up and run projects.

Prerequisites:

• Docker is already installed on WSL.
• NVIDIA’s Container Toolkit is installed on your WSL.

NVIDIA’s Container Toolkit is essential for Docker and GPU integration. Its key features include:

• GPU support: It provides a mechanism to utilize NVIDIA GPUs directly within Docker containers, enabling applications and machine learning models that require GPUs to run efficiently.
• CUDA integration: The toolkit integrates tightly with CUDA, allowing access to CUDA libraries from within a Docker container. This simplifies the development and deployment of CUDA-enabled applications.
• Flexibility and portability: Using containers ensures that applications run consistently across different systems and CUDA versions, which is especially important for GPU-intensive applications.
• Easy setup: The toolkit eliminates the need to include GPU drivers in the container image—as long as the driver is properly set up on the host system, the container can use it.
• End-to-end GPU support: NVIDIA offers comprehensive GPU support for Docker containers, assisting you throughout development, deployment, and scaling.

NVIDIA’s Container Toolkit significantly simplifies the development and deployment of GPU-enabled applications, making it easier to perform machine learning, data science, and other GPU-intensive tasks.

Work with the following GitHub repository:

GitHub

GitHub – Plachtaa/VALL-E-X: An open source implementation of Microsoft’s VALL-E X zero-shot TTS mode… An open source implementation of Microsoft’s VALL-E X zero-shot TTS model. Demo is available in https://plachtaa.github.io/vallex/ – Plachtaa/VALL-E-X

For clarity, create an appropriate directory and navigate to it. Then, create a Dockerfile and script in that directory:

mkdir vall
cd vall
sudo nano Dockerfile

The contents of the Dockerfile are as follows. After some improvements, it is now ready and working:

# Use the official PyTorch image with CUDA 11.8 support
FROM pytorch/pytorch:latest

# Set environment variable to disable timezone prompt
ENV DEBIAN_FRONTEND=noninteractive

# Install necessary packages (including FFmpeg and git)
RUN apt-get update && \
    apt-get install -y python3-pip ffmpeg git && \
    pip3 install --upgrade pip

# Install PyTorch, torchvision, and torchaudio with CUDA 11.8 support
RUN pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

# Upgrade Gradio
RUN pip install --upgrade gradio

# Set working directory
WORKDIR /usr/src/app

# Clone the VALL-E-X repository
RUN git clone https://github.com/Plachtaa/VALL-E-X.git

# Change working directory to the cloned repository
WORKDIR /usr/src/app/VALL-E-X

# Install required packages specified in requirements.txt
RUN pip install --no-cache-dir -r requirements.txt

# Add FFmpeg to the PATH environment variable
ENV PATH="/usr/bin/ffmpeg:$PATH"

# Copy the locally modified launch-ui.py into the container
COPY launch-ui.py .

# Create checkpoints and whisper directories
RUN mkdir -p ./checkpoints
RUN mkdir -p ./whisper

# Define environment variable
ENV NAME World

# Execute launch-ui.py when the container starts
CMD ["python3", "launch-ui.py"]

The script was modified from the launch-ui.py file on GitHub and saved in the same location as the Dockerfile. I needed to add a description to allow access from non-local locations, among other modifications.

sudo nano launch-ui.py

Since the script is long, I have made it available for download at:

気まぐれブログ

記事やYouTube動画で使用した資料 日付順になっています。下に行くほど新しい資料です。2000年からのNT倍率推移2020年3月時点の寄与度ランキングwebスクレイピングサンプルファイルRSSセル参照、代入NT倍率…

Build and create an image based on the Dockerfile:

docker build -t valle .

Launch the container using the created image:

docker run -d --name vall --gpus all -p 7860:7860 valle

Note that the container may appear to be up immediately. However, if you access it right away with a browser, you might encounter an error because the model is still downloading. You can check the status with the following command:

docker logs -f vall

The docker logs -f [container name] command is used by Docker to display the logs of a specific container in real time. Here’s what each part means:

• docker logs: Instructs Docker to retrieve the logs for a given container. All standard output (stdout) and standard error (stderr) from applications and processes run by the container will be displayed.
• -f: This option stands for “follow,” which means to track logs in real time as new output is generated.
• Container Name: This is the unique name assigned to the Docker container for which you want to view logs.

In short, the docker logs -f [container name] command displays the logs for a specific Docker container in real time, which is very useful for debugging and monitoring your system.

Once enough time has passed, you can access the application in your browser. To find the WSL IP address, for example, run:

ip a

Then, open the URL in your browser, such as:

Environments running on WSL have different network settings than the host Windows environment. Key points include:

Private IP address:

WSL typically assigns a private IP address that is different from the host Windows system, because WSL has its own network interface and resides on a separate subnet.

Network isolation:

The different IP addresses mean that WSL is network isolated. Therefore, to access services and applications running within WSL, you must use its IP address.

Communication and port forwarding:

Communication between WSL and the host Windows is possible, but you may need to configure port forwarding and other network settings, particularly for external access.

Development environment implications:

Development environments, such as Python, must account for differences in network access between applications running on WSL and those on the host OS, which is especially important when setting up a local development environment.

If you run a Python script inside the container, you will see a message instructing you to enter the container by typing the following command:

docker exec -ti vall bash

root@709a765560ce:/usr/src/app/VALL-E-X# python3 launch-ui.py default encoding is utf-8,file system encoding is utf-8 You are using Python version 3.10.13 Use 20 cpu cores for computing /opt/conda/lib/python3.10/site-packages/torch/nn/utils/weight_norm.py:30: UserWarning: torch.nn.utils.weight_norm is deprecated in favor of torch.nn.utils.parametrizations.weight_norm. warnings.warn("torch.nn.utils.weight_norm is deprecated in favor of torch.nn.utils.parametrizations.weight_norm.") Running on local URL: http://0.0.0.0:7861 Running on public URL: https://a8d8a69c61a01967a3.gradio.live This share link expires in 72 hours. For free permanent hosting and GPU upgrades, run `gradio deploy` from Terminal to deploy to Spaces (https://huggingface.co/spaces)

Based on the displayed message, it indicates that the application you are using (likely Gradio) has generated a temporary public URL. Specifically:

• Local URL: http://0.0.0.0:7861 is the URL to access the application running in the container on the local network.
• Public URL: https://a8d8a69c61a01967a3.gradio.live is a temporary public URL provided by the Gradio service, allowing external access to your application.
• 72-hour expiration: This public URL expires after 72 hours. If you need permanent hosting or GPU upgrades, consider deploying on Hugging Face’s Spaces platform.

In summary, the message indicates that the application running in the container has generated a temporary public URL, allowing access from anywhere on the Internet. This is a common method for easily sharing applications using Gradio or similar tools.

To use VALL-E X the next time your computer is turned off or for any other reason, start the container with the following command:

docker start vall