[pulseaudio-discuss] pulseaudio over wifi

[Matthew Patterson]

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
>