On 07.04.2016 17:05, Raymond Yau wrote: > > > >> The capture device may already started by other application (e.g. > mic peak of pavucontrol), there is some audio already captured by > driver but not read by server > >> > >> At low latency, usb pointer incremented by number of frames in urb > packet but hda intel increment by frames in dma brust > >> > >> Do the result different when you use hda-intel as source and usb > audio for playback? > >> > > > > It depends on what delay you mean. The delay I am talking about > > above stays the same, but as already said the individual sinks and > > sources have additional small delays of their own. So moving the > > source from HDA to USB increases the overall latency by about 1ms. > > > > If the granularity of two sound cards are differenct? Hda 32 frames > but usb use 44.1 frames ?? Do you have enough frames to start usb > audio when using hda as source after receive 32 frames > Audio is buffered in the memblockq of module-loopback. The memblockq is filled with silence up to the configured latency before starting sink or source. Also source audio is discarded until the sink input has called pop(). Because the filled memblockq is in between, sink and source can be started independently. If source and sink latency are reported correctly, the controller should adjust the latency to the configured value, regardless of the initial state, as long as sane latency values are specified. > > > >> It is unlikey module loopback can achieve lowest latency when you > cannot control start, capture and playback of alsa sink and source > >> > >> It should have latency higher than snd-aloop, alsaloop or latency.c > >> > > > > The low limit of module-loopback seems to be around 5ms end-to-end > latency > > for HDA -> HDA. At this point tons of "memblock.c: Pool full" > messages appear > > in the log and going below 5ms will always lead to underruns. > > #define TSCHED_MIN_SLEEP_USEC (10*PA_USEC_PER_MSEC) /* 10ms */ #define > TSCHED_MIN_WAKEUP_USEC (4*PA_USEC_PER_MSEC) /* 4ms */ > > It is because hda use timer base scheduling which has min sleep and > watermark > Why is then 0.5ms the lowest configurable latency? Should it not be what the code can handle? Down to about 3ms configured sink latency all is fine, below that point messages appear and 2.333 ms seems to be the absolute minimum. Anything below that value causes underruns immediately. > Are there any difference when enable/ disable timer base scheduling > for usb audio? > > Yes, I only see those messages with timer based scheduling, but for USB devices they already start at around 8 or 10ms configured sink latency, which is more than the min sleep and watermark values.
