>> >>> > I don't want to shorten the latency. I only want the latency reported correctly. To me it still >>> > looks like the real latency of the driver is not what it reports, because the time that the >>> > audio spends in the URB's is not taken into account. What I am seeing is, that the real >>> > latency is around 10ms longer than expected. >>> >>> The total number of URBs for the endpoint is not allowed to exceed MAX_URBS (which the patch increases from 8 to 12). >>> >>> Do this match with your measurement >>> >>> >> How much audio does one URB hold? The time I measure is between 8 and 9 ms and does not >> depend much on the configured sink latency as far as I can tell. (I tried latencies between >> around 10ms and 2s). I did however not check the dependency in detail, most observations >> are with sink latencies in the range of 10 - 20ms. >> > OK, I did a few more measurements and the numbers I have given above are not correct. > The actual difference in overall latency is 12ms. > When I run module-loopback with 40ms configured latency, I will see about 42ms with my > code that accounts for the delay and 54ms with the old code. > So if an URB holds 1ms of audio, this could match. > > I think the remaining 2ms are hardware delays, they are slightly different for different > combinations of source/sink and by setting small latency offsets (HDA source: 0ms > HDA sink: 2.8ms, USB source: 1.0ms and USB sink: 1.8ms) I am at 40ms +/-0.5ms > for all combinations. Do module-loopback have higher latency than hda loopback mixing since most hda codecs have analog mixer which support loopback mixing (e.g. mic playback switch) ?