[alsa-devel] Will we ever see a low latency/high performance PCM api for usb, firewire, avb ?

Jaroslav Kysela perex at perex.cz
Fri Apr 26 15:35:29 CEST 2019


Dne 26. 04. 19 v 14:22 Clemens Ladisch napsal(a):
> Jaroslav Kysela wrote:
>> Any idea to improve the transfer method? The problem with the serial buses is
>> that you have to queue usually more samples to avoid underruns.
> 
> When the ALSA buffer is not mmapped, it is possible to treat the contents of the
> packet buffers as the ring buffer, i.e., to write the sample data directly into
> the packets, ideally even after they have been queued.

1) It is possible to force the synchronization of pointers through ioctl even
in the mmap mode:


https://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_hw.c;h=91370a88c0fdece71c8aef96e83837858a583c9b;hb=HEAD#l1757

In this mode, the driver will know when appl_ptr is updated. I don't see
difference between mmap mode and r/w mode here.

2) The driver can disable the mmap mode and the r/w data transfer operations
can be replaced with own callback.


I just don't think that the mmap transfer mode is the culprit of the problems.
The problem is that the PCI cards off-loads the DMA transfers completely
without the extra framing required for those serial hardware interfaces which
are handled in the audio driver and the other kernel stacks (USB etc.).

Anyway, the driver must queue the data timely, so it might be also possible to
use fine grained timer to check the data availability (appl_ptr moves) from
the application ahead (like in the interrupt each 1/2 or 1/4 period time). But
as I wrote, it's not a problem to track the appl_ptr moves using the special
ioctl, too.


						Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.


More information about the Alsa-devel mailing list