Will we ever see a low latency/high performance PCM api for usb, firewire, avb ?

Will we ever see a low latency/high performance PCM api for usb, firewire, avb ?

[Ralf Beck]

Subject says it all.

During the Dec/Jan period i did some USB patches for the Motu AVB series and a trivial alsa driver to connect my Motu via AVB for a single i/o stream. So i discovered how totally unsuitable the mmapped ringbuffer model of alsa is for the above types of interfaces. Is there any intention to change this ?
I've read that this has already been discussed during miniconf 2017 (USB) and 2018 (AVB). Any results?

Re: Will we ever see a low latency/high performance PCM api for usb, firewire, avb ?

[Jaroslav Kysela]

Dne 25. 04. 19 v 22:54 Ralf Beck napsal(a):
> Subject says it all.
> 
> During the Dec/Jan period i did some USB patches for the Motu AVB series and a trivial alsa driver to connect my Motu via AVB for a single i/o stream. So i discovered how totally unsuitable the mmapped ringbuffer model of alsa is for the above types of interfaces. Is there any intention to change this ?
> I've read that this has already been discussed during miniconf 2017 (USB) and 2018 (AVB). Any results?

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. The system
scheduling comes to play, too (no direct DMA transfers from the audio buffer
without further main CPU intervention).

Also, you can write only read/write driver without mmap support (ALSA API
supports this mode). But I don't think that it will help much. If you have
problem to find good ring buffer size / period size settings, it's usually
because of the hardware limitation or the system scheduler settings.

					Jaroslav

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

Re: Will we ever see a low latency/high performance PCM api for usb, firewire, avb ?

[Clemens Ladisch]

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.


Regards,
Clemens

Re: Will we ever see a low latency/high performance PCM api for usb, firewire, avb ?

[Jaroslav Kysela]

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@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.