Re: QUdpSocket and priority
Quote:
Can I increase the priority of this thread?
Increasing the thread priority will not help, in fact even using a thread will not help because you still rely on readyRead() signal which has nothing to with thread, and not effected by thread priority.
I am afraid the packet itself is delayed, so your server cannot do much about it, moreover expecting a packet every 20ms over ethernet (or any shared network) is not practical.
Re: QUdpSocket and priority
I probably do not accurately described the situation.
1 I have server, which receives audiostream. Period between audio (rtp) packets is 20mS. It is ordinary period for rtp packets.
2 I run WireShark and I see packets and period between arriving. Also I see maximum delay between packets.
3 I run server (WireShark works too). Maximum delay between packets is the same in the Wireshark and in the server.
4 I run browser and delay is changed. 250 mS - in WireShark, 800 mS - in the server.
I made an experiment. Instead QUdpSocket I used native socket API (socket(), select() ...) in the server thread. I was running browser and I got the same delay in the WireShark and in the server. I think, when QUdpSocket is created, in the Qt network module is started thread, which monitors the state of the native socket and sends events. This thread has normal priority. (When I run server with QUdpSocket I see one additional thread.(I use "Process explorer" application for Windows).
And I want to increase priority of this thread or any way to speed up the network module.
Re: QUdpSocket and priority
Quote:
I think, when QUdpSocket is created, in the Qt network module is started thread, which monitors the state of the native socket and sends events. This thread has normal priority. (When I run server with QUdpSocket I see one additional thread.(I use "Process explorer" application for Windows).
And I want to increase priority of this thread or any way to speed up the network module.
I don't think QUdpSocket creates a thread. Please check again you might be looking at some other thread.
Re: QUdpSocket and priority
You are right. Work with sockets controlled in the events loop :) Thank you for answers.
Re: QUdpSocket and priority
Whether your program is threaded or not you cannot make your CPU deliver network data if it is busy loading a browser and starting the tens of threads typically needed there. Network jitter like this is why streaming media players buffer some input before they start playing, and presumably also manage a buffer in the audio/video hardware which will play while the CPU is busy. All it may take is to buffer a second or two to cover a potential 500 millisecond glitch. The RTP timestamp is there to allow playback at correct intervals and the sequence allows detection/handling of lost packets (how is up to the receiver).
Qt does use a thread internally to its network code for HTTP (http://peter.hartmann.tk/blog/2012/0...ttp-stack.html) but that should not affect UDP unless Qt5 has done some more in this area.