On Mon, September 23, 2013 6:11 pm, Tanu Kaskinen wrote: > 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. > I've asked for some more details on the ecasound list. If the PA stream buffer is kicking in, Is there any way I can verify if it is happening? is there anything I can do to minimise that affect? >> > 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). > Usually the more information available the better, right? >> 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. > I'm looking into it. -- Patrick Shirkey Boost Hardware Ltd
