Martin,
There are two buffers you are setting - the input and output buffer - so you should count both for an accurate estimate. Additionally, the amount of the input buffer that is used depends on when PD gets around to reading the data, so the amount of latency that it adds varies over time and depends on the patch, machine, etc. Finally, the card is adding some latency in addition to the buffers. This is for the converters when they are used, but I am not convinced that S/PDIF output doesn't require some processing and therefore adds latency (that assumption seems required for the conversion_time to be accurate).
I have been doing some latency experiments of my own with the newest alsa and a 2.4 kernel and have gotten some good results using poll on the soundcard fd instead of using select to sleep (12.2 milliseconds actual latency - 3.5 ms buffers). Miller, it seems like it would be easy to replace the select call with poll. If sys_microsleep was modified with timeout set to 0 for the select of the network socket fds and poll (or possibly select) done immediately after on the soundcard fd it might be possible to wake up a little sooner when data was ready in the soundcard. One nice feature of the newest alsa is that it allows you to specify the minimum amount of data available for poll to return - making it possible to avoid a status check for available buffer space when poll returns. It seems likely to me that this would both lower latency and reduce jitter. Anyway, just an idea - comments?
Karl
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
On Fri, 12 Jan 2001, Martin Marier wrote:
Hello,
I've been trying to perform a latency test with PD. I use the PD 0.32 for linux (unpatched kernel)with ALSA drivers 0.5.9 for my M-audio Delta-66. To test the latency I use a patch that sends an impulse to an output that is looped to an input. I've tested both S/PDIF and analog I/O. The patch is joined.
Here are a few results I get : (-rt and -alsa are also there in my .pdrc)
-audiobuf latency_with_s/pdif latency_with_analog conversion_time
20 37.7324 39.1837 1.45125 19 37.7324 39.1837 1.45125 18 37.7324 39.1837 1.45125 17 37.7324 39.1837 1.45125 16 20.3175 21.7687 1.45125 15 20.3175 21.7687 1.45125 14 24.6712 26.1224 1.45125 13 27.5737 29.0249 1.45125 12 23.22 24.6712 1.45125 11 20.3175 21.7687 1.45125 10 23.22 24.6712 1.45125 9 21.7687 23.22 1.45125 8 23.22 24.6712 1.45125
There must be something I don't understand. Can anyone explain these results ? Does my test make sense ? Thanks
Martin Marier
(here's the patch)
#N canvas 468 248 505 403 10; #X graph graph2 0 -1 3 1 399 396 499 346; #X array click 4 float; #X pop; #X msg 399 309 ; click resize 4 ; click 0 1 0 0 0; #X obj 37 48 tabplay~ click; #X msg 37 28 bang; #X obj 37 67 *~ 0.9; #X obj 126 48 threshold~ 0.4 0 40 0; #X obj 101 66 timer; #X text 36 13 latency with analog; #X obj 37 86 dac~ 1; #X obj 126 29 adc~ 1; #X obj 34 154 tabplay~ click; #X msg 34 134 bang; #X obj 34 173 *~ 0.9; #X obj 123 154 threshold~ 0.4 0 40 0; #X obj 98 172 timer; #X text 33 119 latency with s/pdif; #X obj 34 192 dac~ 10; #X obj 123 135 adc~ 10; #X obj 399 289 loadbang; #X obj 98 193 print latency_with_s/pdif; #X obj 101 87 print latency_with_analog; #X obj 326 169 print conversion; #X obj 347 78 -; #X connect 2 0 4 0; #X connect 3 0 2 0; #X connect 3 0 6 0; #X connect 4 0 8 0; #X connect 5 0 6 1; #X connect 6 0 20 0; #X connect 6 0 22 0; #X connect 9 0 5 0; #X connect 10 0 12 0; #X connect 11 0 10 0; #X connect 11 0 14 0; #X connect 12 0 16 0; #X connect 13 0 14 1; #X connect 14 0 19 0; #X connect 14 0 22 1; #X connect 17 0 13 0; #X connect 18 0 1 0; #X connect 22 0 21 0;