On Sun, 2013-09-22 at 20:03 +1000, Patrick Shirkey wrote: > On Sun, September 22, 2013 4:37 pm, Tanu Kaskinen wrote: > > If you want to get the minimum latency of this path: > > > > jack_delay -> pulseaudio -> application -> pulseaudio -> jack_delay > > > > then you should use an application that reports underruns and lets you > > control the latency that the application requests from pulseaudio. Then > > you can tune the application latency to find the point where you start > > to get underruns. You should also know the maximum internal buffer size > > of the application. You probably need to write that application > > yourself. > > > > I am using ecasound which reports underruns and allows me to set the > internal buffer. I have it set to 64 frames/period for this test. > > It does report occasional underruns but over a 6 hour period I had about > 20. Based on that info it leads me to PA sink as the bottle neck. Do you > have any suggestions about how I can rule that out? The audio is accumulating in some buffer, and the JACK sink in PulseAudio doesn't have any buffer, so it's not the sink. It could be some other buffer in PulseAudio, or it could be a buffer in ecasound. Saying that ecasound is configured with 64 frames/period isn't terribly informative, because I don't know how ecasound handles the transfer from the input to the output. Does it push the data immediately to the output when it gets something from the input, or are both directions callback based? If the former, then the data can accumulate in the stream buffer in PA, and if the latter, then there has to be an intermediate buffer between the input and the output in ecasound, and the data can accumulate there. > > pa_stream_get_latency() gives you an estimate of the latency between the > > hardware and your application. pa_stream_get_timing_info() gives some > > more details about how that latency is split between different parts in > > pulseaudio. > > > > Can you or anyone else recommend an example app that I can use as a > reference for this code? No. And anyway, if you want to really measure the latency (detect when a signal pulse arrives at a measurement point), these functions are useless (except for checking that is PulseAudio reporting the latency correctly or not, which would actually be quite interesting information). > I am thinking of building an app that will let me gather latency data from > both PA and JACK. I would like it to measure the timing of a signal pulse > as it is transferred between each node in the graph. It would communicate > with both JACK and PA at the same time. Do you see any insurmountable > blockers to achieving that goal from a technical perspective in regards to > PA? So you would generate a pulse in a jack client, and detect it in a PA client, and then detect it again in a jack client? No, I don't see any obstacles to doing that. -- Tanu
