Paul Davis wrote: There is no extra buffer for these functions; snd_pcm_write/read* copy the data to/from the same hardware buffer that would be used by the mmap functions. The only case where there is a separate buffer is when the data written by the application is not the same as the data to be written to the hardware, i.e., when using dmix or sample format conversion. But when using those plugins, the read/write and mmap functions still all use the same buffer. Using mmap does not give any latency advantage when the application copies the data from some other buffer into the hardware buffer, i.e., if it does the same as snd_pcm_write. Best regards, Clemens

Paul Davis wrote: Yes. So does snd_pcm_mmap_commit(). Apparently a different algorithm. Louis, can we see your program? Best regards, Clemens

Paul Davis wrote: Reading http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___direct.html at least I understand that readi/writei/readn/writen are just helper functions around mmap_begin/mmap_commit. Essentially it should be possible to do read/modify/write as well as the memcpy actions on mmap buffer, because former can be implemented in user space using latter... - Jussi

On Tue, Sep 8, 2009 at 2:39 AM, Clemens Ladisch<clemens(a)ladisch.de> wrote: the documentation for snd_pcm_writei() notes: "If the blocking behaviour is selected, then routine waits until all requested bytes are played or put to the playback ring buffer. The count of bytes can be less only if a signal or underrun occurred." do you want to clarify your comment about "no additional buffering"?

Practically, for mmap'able devices in addition to waiting, _readi() seems to be doing this inside a loop: snd_pcm_mmap_begin(pcm, &pcm_areas, &pcm_offset, &frames); snd_pcm_areas_copy(areas, offset, pcm_areas, pcm_offset, pcm->channels, frames, pcm->format); result = snd_pcm_mmap_commit(pcm, pcm_offset, frames); (follow the pcm_mmap.c:snd_pcm_mmap_readi() called through vtable)

Louis Gorenfeld wrote: I've written a test program that implements your algorithm, except that both devices are blocking, and that it aborts on xruns. It sends a period containing a sine wave, then copies the recorded data to the output. Ten periods of recorded data are dumped to the output. In the recorded data, there is a silent gap of two periods between each two periods containing data; this is the same behaviour that you see. This can be explained by the following observations: 1) At the start of the loop, the output buffer is full, and the input buffer contains one period of recorded data. Let's assume that the output buffer contains two periods of silence and that the input data contains a signal whose latency you want to measure. 2) The input data period is read and processed. 3) The data is written to the output buffer, but since the buffer is (partially) full, this writing waits while the data of one period in the buffer is still being played. This is one period of silence. At the same time, one period is recorded. 4) In the next loop cycle, one period is read and written. During this time, the second period of silence is played. 5) In the next loop cycle, one period is read and written. During this time, the period containing the recorded signal is played. So, between the end of the period where we recorded the signal and the beginning of the period where the signal was played, there is an interval of two periods, i.e., the overall latency is three periods. This is caused be the algorithm; when we want to write one period of data at the end of step 2) above, we still have (almost) two periods of not-yet-played data in the buffer. To reduce the latency, you would have to keep the output buffer more empty. In my test program, try removing one of the writei calls before the snd_pcm_start. Best regards, Clemens

Louis Gorenfeld wrote: This doesn't matter for the algorithm since I'm only interested in the latency between recording some data and actually playing _that_ data. In my example program, that data is silence so that I can detect the signal. The input data was just read, that is, it was recorded in the time since the last readi() (or since the pcm_start). Because the read did not block. This can happen with certain devices, but usually not with PCI sound cards. It's only a few milliseconds anyway. Yes, but I wrote "removing". This depends on how you manage the output buffer. There are several latencies that add to the overall latency of the program. DMA FIFOs and group delays of the input/output devices are fixed. The input buffering has a fixed latency of one period, because you can structure the algorithm so that the input data is read as soon as a period has been recorded. (The input buffer size does not matter, so you can make it as big as possible to prevent overruns.) The output buffering latency is the time between writing some data to the buffer and the actual playback of that data, and that interval is equivalent to the amount of data that is already in the buffer when you are writing. If the buffer is already completely filled, the entire buffer must be played before your new data, so the entire buffer length determines the latency. With a two-period buffer, the input and output buffering latencies add up to three periods, which is what you are observing in your program. To decrease that output buffering latency, make sure that there is less valid data in the buffer when you are writing. This is initially determined by the amount of data you put into the buffer before starting streaming, and can be later adjusted with snd_pcm_forward/rewind(). So, how much data does your program write into the output buffer before calling snd_pcm_start(), and how exactly does your program determine if it should call snd_pcm_forward() on the output buffer? Best regards, Clemens

On Thu, Sep 24, 2009 at 12:16:45AM +0300, Jussi Laako wrote: More generally, 2) Set number of periods to N (N >= 2) 3) Write N periods of silence to output. This is exactly what Jack's backend and clalsadrv are doing. Both use mmapped access, and also wait on both the read and write fd's (this may be overkill if both streams are sync-started). Both also have some extra code do cleanly recover and restart after an xrun. IIRC the OP wanted to use read/write access. If ALSA allows to call read() so it block until a period is available that would work, in that case you can probably write() without waiting, as the output stream _should_ be ready to accept a period if both streams were started together. Round-trip latency is N periods, plus some extra for the HW. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.