When I submit synthesis requests for text that is too long, I get the following error:
google.api_core.exceptions.ResourceExhausted: 429 Received message larger than max (X vs. 4194304)
Where "X" is the size in bytes of the returned request. Why are requests limited to 4MB? I know that requests are limited to 5000 characters, but my requests are ~1500 characters, nowhere near the limit. Is it possible to receive messages larger than 4MB? Or is the 5000 character limit not the real bottleneck to Google text-to-speech?
If it changes anything, I'm using different en-us Wavenet voices with LINEAR16 encoding.
Here is a programmatic fix (Python) that worked for me (as proposed in this GitHub post: https://github.com/googleapis/python-texttospeech/issues/5#issuecomment-709562585)
from google.cloud import texttospeech_v1
from google.cloud.texttospeech_v1.services.text_to_speech.transports.grpc import (
TextToSpeechGrpcTransport,
)
channel = TextToSpeechGrpcTransport.create_channel(
options=[("grpc.max_receive_message_length", 24 * 1024 * 1024)]
)
transport = TextToSpeechGrpcTransport(channel=channel)
client = texttospeech_v1.TextToSpeechClient(transport=transport)
Related
I've got a working local website that takes in HTML form data.
The fields are:
Temperature
Humidity
The server successfully receives the data and spits out a graph updated with the new entries.
Using a browser tool, I was able to capture the actual POST request as follows:
http://127.0.0.1:5000/add_data
Temperature=25.4&Humidity=52.2
Content-Length:30
Now, I want to migrate from using the human interface browser with manual entries to an ESP01 device using AT commands.
According to the ESP AT-commands documentation, a POST request is performed using the following command:
AT+HTTPCPOST=
Find the link below for the full description of the command.
I cannot seem to get this POST request working. The ESP01 device immediately returns an "ERROR" message without any delay, as though it did not even try to send the request, that the syntax might be wrong.
Among many variations, the following is my best attempt:
AT+HTTPCPOST="http://MYIPADDR:5000/add_data",30,2,"Temperature: 25.4","Humidity: 52.2"
With MYIPADDR above replaced with my IP address.
How do I translate a post request into ESP01 AT command format, and are there any prerequisites needed to be in place to perform such a request?
I did connect the ESP01 device to the WiFi network.
Here's the link to the POST AT command description:
https://docs.espressif.com/projects/esp-at/en/release-v2.2.0.0_esp8266/AT_Command_Set/HTTP_AT_Commands.html#cmd-httpcpost
The documentation says:
AT+HTTPCPOST=url,length[,<http_req_header_cnt>][,<http_req_header>..<http_req_header>]
Response:
OK
The symbol > indicates that AT is ready for receiving serial data, and you can enter the data now. When the requirement of message length
determined by the parameter is met, the transmission starts.
...
Parameters
: HTTP URL. : HTTP data length to POST. The maximum
length is equal to the system allocable heap size.
<http_req_header_cnt>: the number of <http_req_header> parameters.
[<http_req_header>]: you can send more than one request header to the
server.
You're sending:
AT+HTTPCPOST="http://MYIPADDR:5000/add_data",30,2,"Temperature: 25.4","Humidity: 52.2"
The length is 30. The problem is that everything after the length is HTTP header fields; you need to send the variables in the body. So the command is:
AT+HTTPCPOST="http://MYIPADDR:5000/add_data",30
followed on the next line by after the ESP-01 send the > character:
Temperature=25.4&Humidity=52.2
Because you passed 30 as the body length, the ESP-01 will read exactly 30 characters after the end of the AT command and send that data as the post body. If the size of that data changes (for instance, maybe the temperature is 2.2, so one digit less), you'll need to send the new length rather than 30.
I have developed a client and a server using swift nio, I have no problems sending package of all size between 12 and 1000bytes since server sends a pack of 528bytes and when client got it, it is 512bytes. I'm trying to figure out why it happens. Does anyone knows if there is any chance to set a minimum ByteBuffer capacity? or if I'm missing something.
Thanks to all.
Assuming you're using TCP (that is, using ClientBootstrap), you cannot expect that the boundaries of messages sent by the server will be reflected in your reads. TCP is "stream-oriented": this means that the messages don't have boundaries at all, they behave just like a stream of data. In the NIO case, that means you would expect to see another read shortly after that contains more data.
The initial ByteBuffer capacity used for reads is controlled by the RecvByteBufferAllocator used by the Channel. This can be overridden:
ClientBootstrap(group: group)
.channelOption(ChannelOptions.recvAllocator,
AdaptiveRecvByteBufferAllocator(minimum: 1024, initial: 1024, maximum: 65536))
The standard defaults for the AdaptiveRecvByteBufferAllocator in NIO 2.23.0 are a minimum size of 64 bytes, an initial size of 1024 bytes, and a maximum size of 65536 bytes. In general we don't recommend overriding these defaults unless you need to: for TCP NIO will ensure the buffer is appropriately sized for the reads we're seeing.
My gateway uses the Raspi and RFM95 configuration and operates at 915 MHz. I am using the single channel packet forwarder code by tfelkamp (https://github.com/tftelkamp/single_chan_pkt_fwd).
My gateway only the detects the first message it received and ignores the all messages afterwards. It is still connected to the TTN server but does not receive any more messages.
Can anyone explain what might be the cause of this? Might it because the RFM95 sleeping or the code no longer forwarding the message from the transceiver.
Thanks
I experienced a similar issue. Please note your sender is using different channels, but starts with channel(0). This is the first successful message you receive. Your single channel receiver is just able to receive channel(0). There is a work around for this issue for your sender explained here
This sounds like your transmitter sends the messages using frequency-hopping, while your receiver does not handle it correctly (or the other way around).
Definition of frequency-hopping found in chapter 4.1.1.8 of Semtech's SX1272 datasheet:
Frequency hopping spread spectrum (FHSS) is typically employed when
the duration of a single packet could exceed regulatory requirements
relating to the maximum permissible channel dwell time. This is most
notably the case in US operation where the 902 to 928 MHz ISM band
which makes provision for frequency hopping operation. [...]
If you're using the LMIC-Arduino library for your node then yes, by default it is transmitting in a range and the single_chan_pkt_fwd gateway is only receiving on the frequency you specify in the global_conf.json or the .cpp source (depending on your chosen library).
With the assumption that you're using the arduino-lmic library, make the changes/additions mentioned in the this TTN forum post linked by Rainer which is the same I ran into.
Also... you'll find this further down the thread: in src > lmic > lmic.c edit the following:
void LMIC_disableChannel (u1_t channel) {
if( channel < 72+MAX_XCHANNELS )
//LMIC.channelMap[channel>>4] &= ~(1<<(channel&0xF)); // comment this one
LMIC.channelMap[channel/16] &= ~(1<<(channel&0xF)); // add this one
}
Then pick a frequency on channel 0 and set that for both node and packet forwarder. Here's a table snip from this page. I went with 902300000 and it's working fine.
"freq": 902300000,
"spread_factor": 7,
Is it possible to throttle the bandwidth of an upload operation in e.g. Alamofire?I would like to upload data in the background while the user is using the app and up- and downloading more important stuff.Therefore, I would like to throttle the bandwidth in the background under specific circumstances.
The only possibility I found so far is using ASIHTTPRequest, which has a maxBandwidthPerSecond property, but that library is far too old, I would like to use something newer.
The Chilkat API provides a CKOSocket() that provides the possibility to throttle the used bandwidths like this:
// To use bandwidth throttling, the connection should be made using the socket API.
// This provides numerous properties to customize the connection, such as
// BandwidthThrottleDown, BandwidthThrottleUp, ClientIpAddress, ClintPort, Http Proxy,
// KeepAlive, PreferIpv6, RequireSslCertVerify, SoRcvBuf, SoSndBuf, SoReuseAddr,
// SOCKS proxy, TcpNoSDelay, TlsPinSet, TlsCipherSuite, SslAllowedCiphers, etc.
let socket = CkoSocket()
var maxWaitMs: Int = 5000
var success: Bool = socket.Connect("content.dropboxapi.com", port: 443, ssl: true, maxWaitMs: maxWaitMs)
if success != true {
print("\(socket.LastErrorText)")
print("Connect Fail Reason: \(socket.ConnectFailReason.integerValue)")
return
}
// Set the upload bandwidth throttle rate to 50000 bytes per second.
socket.BandwidthThrottleUp = 50000
Check this for further documentation.
The example in the documentation demonstrates how to use upload bandwidth throttling with the REST API. It will upload a file to Drobox using a file stream, with a limit on the bandwidth that can be used for the transfer.
I cannot find anything about Alamofire (swift part) but you could use AFNetwork.
As you can see from this link (AFNetworking/AFNetworking/AFURLRequestSerialization.h) the sources report:
/**
Throttles request bandwidth by limiting the packet size and adding a delay for each chunk read from the upload stream.
When uploading over a 3G or EDGE connection, requests may fail with "request body stream exhausted". Setting a maximum packet size and delay according to the recommended values (`kAFUploadStream3GSuggestedPacketSize` and `kAFUploadStream3GSuggestedDelay`) lowers the risk of the input stream exceeding its allocated bandwidth. Unfortunately, there is no definite way to distinguish between a 3G, EDGE, or LTE connection over `NSURLConnection`. As such, it is not recommended that you throttle bandwidth based solely on network reachability. Instead, you should consider checking for the "request body stream exhausted" in a failure block, and then retrying the request with throttled bandwidth.
#param numberOfBytes Maximum packet size, in number of bytes. The default packet size for an input stream is 16kb.
#param delay Duration of delay each time a packet is read. By default, no delay is set.
*/
- (void)throttleBandwidthWithPacketSize:(NSUInteger)numberOfBytes
delay:(NSTimeInterval)delay;
#end
You could build a your custom "NetworkManager" class in objective-C and easily import it to your swift project.
I have a LR script and I am using to make a call on a REST API to download a file. The file gets downloaded successfully but I also need the value of the file size downloaded for verification purpose. Here is what i see in loadrunner console.
Action.c(50): web_custom_request("GetImage") was successful, 2373709 body bytes, 528 header bytes, 99 chunking overhead bytes.
How can I get the value 2373709?? I tried using the below code but the size it returns is a little bit different from the above mentioned and is not solving the purpose.
HttpDownLoadSize=web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE);
lr_output_message("File Size %i", HttpDownLoadSize);
Any help would be appreciated. Thanks in advance for you help.
HTTP_INFO_DOWNLOAD_SIZE property stores the last HTTP response total download size. This includes total size of headers and bodies of all responses, and possible communication overhead. 2373709 body bytes is the total body size of all responses got in a particular step, so if there are several requests/responses in your custom request step, this number will be greater then the actual file size.
I'd suggest validating your response body size. There is no standard API to retrieve it though (at least, in LR 12.53, the latest available version). As far as I see, your response is chunked so I cannot suggest you any efficient methods to do this. Here is rather inefficient method based on storing the whole body to a temporary buffer (twice!):
unsigned long length = 0;
char* tmp = 0;
web_reg_save_param_ex(
"ParamName=Body",
"LB=",
"RB=",
SEARCH_FILTERS,
"Scope=Body",
"RelFrameID=1",
LAST);
web_custom_request(...);
lr_eval_string_ext("{Body}", strlen("{Body}"), &tmp, &length, 0, 0, -1);
lr_output("body length is %d", length);
lr_eval_string_ext_free(&tmp);
Also you might need to increase the maximum HTML parameter length using web_set_max_html_param_len().
However, if you had a non-chuncked non-compressed response containing Content-Length header, you could validate it more efficiently:
web_reg_find("Text=Content-Length: 2373709",
"Search=Headers",
"RelFrameID=1",
LAST);
web_custom_request(...);