On Sat, September 28, 2013 3:12 am, Patrick Shirkey wrote: > >> On Sat, September 28, 2013 12:53 am, Tanu Kaskinen wrote: >> I don't remember if the alsa compatibility layer forwards the >> stream under/overrun notifications to the alsa application - IIRC there >> were problems when those were reported and there were different >> problems >> when those were not reported, and I don't remember what the current >> code >> does. >> This seems like it would be a good place to verify. Do you have any suggestions for how to test/measure the code/buffer at this point in the graph? Also does anyone know why the PA Stream Buffer is hovering around 10ms? That number doesn't appear to match the 64 frames/period that JACK is set to so it would be useful to verify that it is calculated correctly and/or if it can be lowered. > > This is with a newer version of jack_delay which I didn't know about until > a few minutes ago. > > http://boosthardware.com/pa-jack-latency-2.txt > > The results are better which is encouraging but the variation is still > happening just on a smaller scale. > According to Fons Adriaensen the newer version gives more accurate results because it uses 12 signal modes to make the measurement instead of 4 which is what the older version of jack_delay uses. -- Patrick Shirkey Boost Hardware Ltd
