I have an application, that reads opus packets from a file. The file confirms opus packets in ogg format. My application sends each opus packet every 20 millisecond (it is configurable).
For 20 millisec, it sends packets of sizes ranging from 200 bytes to 400 bytes, say average size is 300 bytes.
Sending 300 bytes for 20millsec, is it right or its too much of data. How can I calculate for 20millisec how much data (in bytes) I can send to remote.
Can somebody help me to understand how to calculate number of bytes I need to send to remote party per 20millisec.
300 bytes/packet × 8 bits/byte / 20 ms/packet = 120 kbit/s
That is enough for good quality stereo music. Depending on the quality that you need, or if you are only sending mono or voice, you could potentially reduce the bitrate of the encoder. However if you are reading from an Ogg Opus file then the packets are already encoded, so it is too late to reduce the bitrate of the encoder unless you decode the packets and re-encode them at a lower bitrate.
Related
I have a question about the UDP protocol.
I want to stream data from a particle sensor (Xilinx FPGA Dev Board) to a raspberry pi (or Windows 10 laptop) via UDP byte socket as binary data. I don't care if some packets are lost, because there are many particles coming after anyways... But if a packet gets lost, all of the particles information should get lost.
The connection is a short lan cable over the 1 Gbit/s Ethernet port.
The "minimum" amount of data is 192 Bit (24 Byte) per particle (16 x 12 Bit value) and the maximum amount of particles is 3300 per second.
So I have to transfer max. 192 x 3300 = 79200 Byte/s plus Header etc.
Maximum packet size of UDP 65.507 Byte
As I understand the packet size has to be devidable by 24 Byte in my application.
Which leaves me with a packet size range of 24 to 65.496 Byte.
But if the concentration is lower I don't want to wait minutes until a packet is filled and ready to be send.
What would you guys suggust in regard of repitition rate and size?
E.g. a 1008 Byte packet has to be send about every 13 ms at max. particle concentration.
best regards
I just tested a UDP socket with 1024 Byte Buffer, which works nice with strings or Bitvectors for single test packets.
I have opus packets which is merged from 2 frames.
Size of packet can be great than 255 byte (max segment size in ogg page)
I can split this packet into two packets with single frame and save each in separated segment.
But... Can we simple split packet into parts\chunks 255 bytes + last part less then 255
ang put it in sequence segments into ogg page?
It doesn't work to me (maybe incorrect code). But I am interesting how to handle it properly? We really need to repack doubled packets to separated packet? or not?
Sorry for my pure english.
No need to repacketize. I forgot about special case when length of packet is 255, we need add 0 to segment table
i want help in OPUS DTX
1.how OPUS DTX is working.
2.how opus encoder and decoder works for dtx
3.Is there any bit representation for DTX in OPUS
From rfc When DTX is enabled, only one frame is encoded
every 400 milliseconds it didnt works for me with opus_demo binary.
please help with OPUS DTX.
When using Opus over a network, using a protocol such as RTP where the packets are timestamped, DTX may be enabled if you want to reduce the packets sent during periods where there is no voice activity. A packet would still be sent about every 400 ms, updating background noise. Using the packet timestamps the receiver can determine the duration of any gaps and fill them in with the background noise to keep it sounding natural.
Enable DTX in the encoder using opus_encoder_ctl(enc, OPUS_SET_DTX(1));, or with the -dtx option on opus_demo. Then, simply do not send any packets produced by the encoder with a length of 2 bytes or less. (These "DTX packets" are just zero-length frames, with a normal 1- or 2-byte packet header (TOC), and do not contain any audio data.) Packets with a length larger than 2 bytes should be sent as usual.
The receiver should use normal packet loss concealment to handle missing packets, in the same manner as it would handle packet loss. In particular it can call opus_decode() with data = NULL, len = 0, and frame_size equal to the size of the missing frame(s), and the decoder will generate audio data to conceal the missing frame(s).
I've been tinkering around with the BLE (Bluetooth Low Energy) connectivity classes quiet a bit lately and haven't been able to make it transfer data any faster than 1KB / 5 seconds. I believe, in the documentation, it says the max speed is 60 bytes per 20 milliseconds. With data transfer and counting the Ack transfer after each set of packets, I believe we should be able to go as fast as 1.5KB per second. So my code is around 7-8 times slower than it should be.
I'm just wondering if anyone has been able to do data transfer in BLE as fast as the documentation says it should be able to do. What sort of speed are you getting if faster than mine?
Thanks a lot
see at the guidlines of apple and you will see that a connection update request is required to speed up your connection.
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
I have min=20ms max 40 ms
I hope I could help
Roman
If you are able to use higher MTU size (negotiated by the iOS) then you would be able to increase the bandwidth even more, because there is a 4 byte L2CAP header and a 3 byte ATT header that wouldn't be transmitted more than in one packet.
If you are able to transmit 6 packets pr connection interval, then you would be able to put in 35 byte extra per connection interval (the 7 byte header would still be there for the first packet) The MTU size could also be split over several connection intervals, increasing the throughput with 7 more bytes pr connection interval. (Just takes longer time to assemble the packet again.) The max MTU size allowed by ATT is 515 bytes (Max size of att is 512 bytes + 3 byte header for opcode + handle)
I am playing MP3 audio form a network stream and sometimes gaps are present when using WIFI connection.
I decrease the buffer size, but I am wondering what is the best method for calculating buffer size.
My MP3 stream is 64 Kbits.
I am using 3 buffers, for 64 *1024 each.
PacketDescriptions is 512
Thanks a lot
Thierry
I found the answer!
Best values for me are :
Number of buffers 3
Buffer size 32 * 768
Max packets description 4096
I wonder why did you choose only 24576 bytes.
Wasn't it so small for buffer?