#I'm currently using the websocket TTS API (eleven_turbo_v2) and I was attempting to setup a progre

1 messages · Page 1 of 1 (latest)

carmine canyonBOT
#
AI-generated Answer for zorro1rr

The method you're using to estimate the file size is based on the assumption that the text-to-speech conversion will result in a constant bitrate audio file. However, this might not always be the case, especially when using advanced text-to-speech models like ElevenLabs' Turbo v2. The actual size of the audio file can vary based on several factors, including the complexity of the input text and the specific characteristics of the voice model.

Unfortunately, the provided content does not include a method for accurately estimating the total upload size based on the text for the websocket TTS API. The actual size of the generated audio can vary and might not be directly proportional to the length of the input text.

As for the progress bar, one approach could be to update it based on the number of text chunks that have been processed, rather than the size of the audio data received. For example, if you're sending the text in chunks of 100 characters, you could update the progress bar each time a chunk is sent or when you receive an audio response for a chunk. This wouldn't give you a progress bar based on upload size, but it would give users some feedback on the progress of the text-to-speech conversion.

Remember to handle the case where the text is less than the chunk size, as this could lead to the progress bar reaching 100% before the conversion is complete. You could handle this by setting the progress bar to 99% until you receive the final audio data, at which point you could set it to 100%.

Please note that this is a general suggestion and might need to be adjusted based on the specifics of your application and the ElevenLabs API.

fallen raptor
#

how can i know what size the data chucks are that are being sent?

carmine canyonBOT
#
AI-generated Answer for zorro1rr

The size of the data chunks being sent can be determined by the CHUNK_SIZE constant in your script. In the Python example provided in the knowledge base, the CHUNK_SIZE is set to 1024. This means that the data is read and written in chunks of 1024 bytes at a time.

Here's the relevant part of the code:

# Define constants for the script
CHUNK_SIZE = 1024  # Size of chunks to read/write at a time

# ...

# Check if the request was successful
if response.ok:
    # Open the output file in write-binary mode
    with open(OUTPUT_PATH, "wb") as f:
        # Read the response in chunks and write to the file
        for chunk in response.iter_content(chunk_size=CHUNK_SIZE):
            f.write(chunk)

In this code, response.iter_content(chunk_size=CHUNK_SIZE) is used to read the response in chunks of size CHUNK_SIZE. Each chunk is then written to the output file. This means that the data chunks being sent are of size CHUNK_SIZE, which is 1024 bytes in this case.

fallen raptor
#

I'm using js here is my code
socket.onopen = function () {
const bosMessage = {
text: " ",
voice_settings: {
stability: 0.7,
similarity_boost: 0.8,
},
xi_api_key: import.meta.env.VITE_ELEVENLABS_KEY, // replace with your API key
};

  socket.send(JSON.stringify(bosMessage));

  // 3. Send the form content
  const textMessage = {
    text: content.chapter_body,
    try_trigger_generation: true,
  };

  socket.send(JSON.stringify(textMessage));

  // 4. Send the EOS message with an empty string
  const eosMessage = {
    text: "",
  };

  socket.send(JSON.stringify(eosMessage));
};
carmine canyonBOT
#
AI-generated Answer for zorro1rr

The size of the data chunks being sent can be calculated by converting the JSON string to a Blob and then checking the size of the Blob. Here's how you can do it:

function getMessageSize(message) {
    const blob = new Blob([JSON.stringify(message)], {type : 'application/json'});
    return blob.size;
}

socket.onopen = function () {
    const bosMessage = {
        text: " ",
        voice_settings: {
            stability: 0.7,
            similarity_boost: 0.8,
        },
        xi_api_key: import.meta.env.VITE_ELEVENLABS_KEY, // replace with your API key
    };

    console.log("BOS message size:", getMessageSize(bosMessage));
    socket.send(JSON.stringify(bosMessage));

    // 3. Send the form content
    const textMessage = {
        text: content.chapter_body,
        try_trigger_generation: true,
    };

    console.log("Text message size:", getMessageSize(textMessage));
    socket.send(JSON.stringify(textMessage));

    // 4. Send the EOS message with an empty string
    const eosMessage = {
        text: "",
    };

    console.log("EOS message size:", getMessageSize(eosMessage));
    socket.send(JSON.stringify(eosMessage));
};

This will log the size of each message in bytes before it is sent. Please note that this size includes the overhead of the JSON formatting and any additional fields in the message, not just the text content.

fallen raptor
#

and what value should I compare that to create a progress bar

carmine canyonBOT
#
AI-generated Answer for zorro1rr

The size of the data chunks being sent can be calculated by converting the JSON stringified message to a Blob and then checking the size of the Blob. Here's how you can do it:

const textMessage = {
  text: content.chapter_body,
  try_trigger_generation: true,
};

const messageString = JSON.stringify(textMessage);
const messageBlob = new Blob([messageString], {type: 'application/json'});
const messageSize = messageBlob.size; // size in bytes

However, creating a progress bar based on this might be challenging because the WebSocket API does not provide a built-in way to track the progress of a message being sent. The socket.send() method does not return a promise and does not provide any progress events.

Moreover, the size of the text message being sent to the server does not directly correlate with the size of the audio data being received. The audio data size depends on the length and complexity of the text, the voice settings, and the audio format.

If you want to provide some feedback to the user during larger uploads, you might consider breaking the text into smaller chunks and updating the progress bar each time a chunk is sent or when a response is received from the server. However, this would be an approximation and might not accurately reflect the actual progress of the audio generation.

fallen raptor
#

are there any plans to implement some kind of response that returns progress events to the websocket api?