I have to implement a little software that sends an audio stream between two pc in the same WiFi network..
In little words, I get audio from device like a mic and then I have to transmit this audio in real time..
maybe I'll use Java..
To transmit data trough UDP something like this:
//create UDP socket
DatagramSocket socket = new DatagramSocket();
//data to be sent
byte[] buf = (data).getBytes();
//create UDP packet
DatagramPacket packet = new DatagramPacket(buf, buf.length, address, port);
//send the packet
socket.send(packet);
...
Well, my question is, how can I split the audio source in packets that I'll store in buf?
how can I receive the packets in another pc and then "reassembly" or play directly?
It's the right way? Thanks very much. Hi!
Why don't you use TCP instead of UDP? With TCP sockets, you'll have stream functionality implemented with no extra hassle.
If you stick with UDP, you'll have to implement some kind of packet numbering, then reassembly, then play only when you have them all, and so on. Try to avoid it.
Related
I have to create a service which captures the audio from the PC microphone and to broadcast it as UDP packets. I am on a Debian platform and I have to use Python (3.7).
I would like to use PyAV because I have to link this broadcasting system to a local custom WebRTC service using aiortc, which relies on PyAV.
I have to do this because I cannot access the same audio source (ALSA) from several processes (RTC peers), so I was thinking to create a UDP broacasting system in a localhost environment. Is this the best practice? Have you any other idea?
I have noticed here that with the call: av.open("udp://xxx:nnn", format="alsa") I should be able to receive audio UDP packets, but I am not sure how to generate a UDP server which captures from the mic and sends the UDP packets, so, how to create the server side of this implementation? In particular, I managed to capture the audio with: av.open("hw:0", format="alsa"), how can I send the captured buffer over UDP sockets?
Can anone explain how it works when an application sends UDP unicast datagrams over an 802.11 WiFi network? Assume non-blocking UDP socket. For concreteness, assume 802.11n or 802.11ac and a reasonably new Linux kernel (Android Lollipop or Debian stable). Specifically, if the sender NIC does not receive any positive ACK of send MPDUs, will the send() call return -1 and socket send queue in kernel be shown as non-empty with netstat? And the NIC will re-send same MPDUs repeatedly?
If this is not the right place to ask, please point to a good reference or another StackExchange site maybe.
In my understanding. Wifi(layer 2) would NOT care about UDP/TCP protocol, for wifi hardware, it is just a frame,
the cast will act like this.....
frame sending -> no ack -> retry again -> no ack -> retry -> no ack -> retry ...
after a few retry, wifi hardware will drop this frame and send next frame in NIC buffer. wifi driver should NOT always keep this frame, because frame drop or lost is frequently case in wifi.
then we talk about UDP network protocol now, because it's anon-blocking UDP socket, UDP would not care any error, it just continue sending and sending and sending....
Android phone has a feature -- "miracast", it also use UDP as a video streaming protocol and use wifi to transfer data. maybe you can check how does this function work.
Layer-2 (Wi-Fi, in this case) knows nothing about the layer-3 protocol (IP, IPX, etc.) used, much less the layer-4 protocol (TCP, UDP, SPX, etc.) used: Wi-Fi doesn't know about IP, which doesn't know about UDP. The whole point of the network layers is that they are independent of each other. Wi-Fi can carry any layer-3 protocol, which, in turn, can carry any layer-4 protocol, which can carry any upper layer protocols.
I have been using UDP sockets to send and receive voice through RTP packetization. It is pretty straightforward. I just send my mic voice signals ( that are encoded ) over IP using User Datagram socket , and on the other end i receive the UDP-RTP packets and decode them to be able to play them on my speakers.
I have been searching on internet for a while to find a way to start up a session using UDP sockets. What i want to to is to a Handshake-like process between two ends of my conversation and after the requests were acknowledged the media layer ( which i described in first paragraph ) would fire and start sending voice.
I have not been able to find any tutorials on session request using UDP sockets but i suppose it shouldnt be impossible.( one user sends a request to build a session and if the other user confirms media layer starts)
Has anyone done something like this before? any info is welcome.
Firstly, UDP is a connectionless, unreliable protocol, you won't find anything like handshaking for negotiating connection i.e no session management. But, to transport RTP packets it's not a good idea to use tcp, it lacks realtime feature, so you have to stick with UDP. Now, to overcome the signaling problem you can use protocols like. SIP. It's standard signaling protocol used in VOIP. SIP initiates a connection before sending RTP packets. To properly use SIP and RTP you might have to take help of another protocol called SDP, which tells which port to use for transmitting RTP and other various info. You can get more info about these techniques here. Hope this will helps!
For my application, I need to intercept certain TCP/IP packets and route them to a different device over a custom communications link (not Ethernet). I need all the TCP control packets and the full headers. I have figured out how to obtain these using a raw socket via socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)); This works well and allows me to attach filters to just see the TCP port I'm interested in.
However, Linux also sees these packets. By default, it sends a RST when it receives a packet to a TCP port number it doesn't know about. That's no good as I plan to send back a response myself later. If I open up a second "normal" socket on that same port using socket(PF_INET, SOCK_STREAM, 0); and listen() on it, Linux then sends ACK to incoming TCP packets. Neither of these options is what I want. I want it to do nothing with these packets so I can handle everything myself. How can I accomplish this?
I would like to do the same thing. My reason is from a security perspective… I am wanting to construct a Tarpit application. I intent to forward TCP traffic from certain source IPs to the Tarpit. The Tarpit must receive the ACK. It will reply with a SYN/ACK of its own. I do not want the kernel to respond. Hence, a raw socket will not work (because the supplied TCP packets are teed), I need to also implement a Divert socket. That's about all I know so far… have not yet implemented.
I have a Linux application that opens a UDP socket and binds it to a port. I haven't had any problem sending unicast packets through the socket. I had occasion to send a broadcast packet, so I enabled SO_BROADCAST, which allowed the broadcast packets to pass, but then I noticed that the unicast packets were being broadcast as well. Is this expected behaviour for a UDP socket, or is it more likely that I've misconfigured something?
From what I understand SO_BROADCAST is a socket option. So if you enable it on your socket this socket will broadcast. I guess you will need to open different sockets if you want to do unicast and broadcast from the same code.
I have not done much hands on programming here, but you probably need to provide more information about the library, OS version, code, etc. Maybe a code sample?
If I remember the books I read, if you set the flag on the socket, that is going to affect all datagrams sent from the socket, because the socket is a basically a data structure of network flags + a file descriptor.
I have figured out the same issue on Linux about having a socket getting unicast and broadcast at the same time. I solved the problem as follow (pseudo-code):
sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
Open the socket
setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &1)
Allows incoming and outgoing broadcast from this socket
bind(sock, bindaddr, sizeof(struct sockaddr) with
bindaddr.sin_family = AF_INET
bindaddr.sin_port = <YourPort>
bindaddr.sin_addr.s_addr = INADDR_ANY
Get all incoming messages on any card for <YourPort>
The caveat is that there is no filtering (see caveat in 3.). So you will get all messages.
The sent messages are either unicasted or broadcasted depedning on the given address in the sendto().