On Sun, Jun 30, 2013 at 7:42 AM, James Stone <span dir="ltr"><<a href="mailto:jamesmstone@gmail.com" target="_blank">jamesmstone@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>In trying to get support with this usb problem in kernel 3.8:</p>
<p><a href="https://bugs.launchpad.net/bugs/1191603" target="_blank">https://bugs.launchpad.net/bugs/1191603</a></p>
<p>I have been asked to provide info on what the period size in jack is and how the round trip latency is calculated.</p>
<p>The dev can't see how with a 1ms latency (which is what jack is using with a period size of 256 samples) the round trip latency is around 10ms.</p>
<p>I have quoted bits of the jack manual page but he doesn't find this helpful and I have now reached the limits of my understanding of the matter and can't find any more detailed descriptions on the web.</p>
<p>It would be great if someone with a more in-depth understanding could help out here!</p><span class="HOEnZb"><font color="#888888"></font></span></blockquote><div><br>Actually, re-reading his reply, I think he has worked most of it out, and the main problem was me not providing enough info.. But now it seems to have got down to how jack actually communicates with the usb driver.. Seems to me it must be a kernel-side problem because it works on 3.5 - but apparently the code for 3.5 was not doing it the "right way"..<br>
<br>He writes:<br><br>"The usbmon trace for 3.5 shows that the audio driver was really using 
the equivalent of 5.5 frames/period and 8 periods/buffer.  This means 
the actual latency (as far as the kernel is concerned) was 5.5 / 44100 =
 0.125 ms, as I mentioned earlier.  The usbmon trace for 3.8 shows that 
the audio driver was really using the equivalent of 11 frames/period and
 8 periods/buffer, for a latency of 11 / 44100 = 0.25 ms."<br><br>James <br></div></div>