>From what I can find the latency calculations do not include any compensation for
packet size. So the latency discovered with the small packet used to measure the
latency is the same number that is applied to larger packets ( carrying audio data ).
The code I'm looking at is in src/pulse/stream.c in function stream_get_timing_info_callback
where is does a straight diff between two timestamps to get a transport_usec delay
I'm using WRT54GS with DD-WRT firmware and I beleive that "frame bursting" is allowing me to
send large packets without significant extra overhead. My internal MTU is
currently set to 2346.
I ran the tests again over 100TX ethernet and the latency went from just under
1 millisecond to just over 2.5 milliseconds. So here, the change in packet size
has negligible effect.
There is another post earlier this month by Col who is also having trouble getting
pulse to work over wifi as well.
Also, how often is mail sent out from this list. I seem to have stopped receiving it?
I've created this reply by cutting and pasting from the web interface.
- Russell
2.31/64 = 0.036
10.8/1032 = 0.0104
153/16392 = 0.009
Preamble size (802.11b, assuming long) 128 bits = 16 bytes.
2.31/(64 + 16) = 0.0289
10.8/(1032 + 16) = 0.0103
153/(16392 + 16) = 0.0093
So it looks to me like there is a bit of overhead involved with smaller
packets on your device, in general (from the 3 data points) the time per
bit is pretty linear. So depending on how the algorithm for latency
calculation is done the size of the packet may be a moot point. With a
correction factor for the packet overhead and a calculation based on the
number of bytes in the packet things should be fine. I have not looked
at the code though, so who knows, maybe it needs some tweaking.
Also, what sort of device are you using? Sending a packet with 16K in it
seems like you are on a pc with GigE and jumbo frames. I thought
generally the internal MTU of networks was 1500? If the wireless device
is not able to handle those jumbo sized frames and that is what pulse is
sending you may have just found your problem. Wireless devices already
have the problem of subpacketising things to large for the radios, so
jumbo packets could well be overloading the processor/buffering
available in your router. I know my router craps out with large volumes
of multicast traffic, maybe yours has a different weakness :)
Matt
Russell Strong wrote:
>/ I have a theory about why I can't get pulse audio to work over wifi (
/>/ using tunnel ), however all my attempts to test it have not worked out
/>/ well ( lack of understanding of the code ).
/>/
/>/ Please correct any assumptions:
/>/
/>/ 1. Pulseaudio uses a small packets containing timestamps to measure the
/>/ round trip time, i.e. the latency.
/>/ 2. The packets used to transfer audio data are considerably larger than
/>/ this.
/>/ 3. Doing some experiments with ping, I see that latency changes a lot
/>/ with packet size. See the difference with the 3 packet sizes below.
/>/ 64 bytes from brain.localnet (192.168.42.3): icmp_seq=2 ttl=64
/>/ time=2.31 ms
/>/ 1032 bytes from brain.localnet (192.168.42.3): icmp_seq=2 ttl=64
/>/ time=10.8 ms
/>/ 16392 bytes from brain.localnet (192.168.42.3): icmp_seq=1 ttl=64
/>/ time=153 ms
/>/
/>/ From this, I conclude that the measurement of latency, using a small
/>/ packet, will not indicate the real latency.
/>/
/>/ To test this I tried to attach a dummy payload to the latency
/>/ measurement packets, but I keep getting protocol errors where my client
/>/ get kicked.
/>/
/>/ Ultimately I'd like to try piggybacking the latency measurements onto
/>/ the actual audio data transfers, keep a history from which I can
/>/ calculate the mean and standard deviation, then set the latency to mean
/>/ + 3*stddev. However, that is beyond my knowledge of the code, so far.
/>/
/>/ Here is a patch showing how I tried to beef up the size of the latency
/>/ measurement packet. Can anyone tell me where I've gone wrong?
/>/
/>/ diff -ur ../pulseaudio-0.9.10/src/pulse/stream.c ./src/pulse/stream.c
/>/ --- ../pulseaudio-0.9.10/src/pulse/stream.c 2008-03-28
/>/ 09:29:27.000000000 +1000
/>/ +++ ./src/pulse/stream.c 2008-06-26 11:53:07.000000000 +1000
/>/ @@ -1140,6 +1140,7 @@
/>/ pa_tagstruct *t;
/>/ struct timeval now;
/>/ int cidx = 0;
/>/ + static uint8_t typical_payload[16384] = {0};
/>/
/>/ pa_assert(s);
/>/ pa_assert(PA_REFCNT_VALUE(s) >= 1);
/>/ @@ -1162,6 +1163,7 @@
/>/ &tag);
/>/ pa_tagstruct_putu32(t, s->channel);
/>/ pa_tagstruct_put_timeval(t, pa_gettimeofday(&now));
/>/ + pa_tagstruct_put_arbitrary(t, typical_payload);
/>/
/>/ pa_pstream_send_tagstruct(s->context->pstream, t);
/>/ pa_pdispatch_register_reply(s->context->pdispatch, tag,
/>/ DEFAULT_TIMEOUT, stream_get_timing_info_callback, pa_operation_ref(o),
/>/ (pa_free_cb_t) pa_operation_unref);
/>/
/>/
/>/
/>/ Russell Strong
/>/ _______________________________________________
/>/ pulseaudio-discuss mailing list
/>/ pulseaudio-discuss at mail.0pointer.de <https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss>
/>/ https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
/>/
/
