[alsa-devel] (no subject)

[Jaroslav Kysela]

Dne 13. 06. 19 v 7:54 Ralf Beck napsal(a):
> 
> Jaroslav Kysela wrote:
>> 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.).
> 
> The source of all evil is the ring buffer.
> It prevents all devices that require packet headers (Firewire/network based solutions) or that
> use a variable amount of frames per packet (all asynchronous devices, especially asynchronous USB ISO endpoints)
> from mapping their data directly into userspas memory without ever touching the audio data in it.
> 
> While this doesn't hurt performance to much with devices that offer only a few channels,
> it has a massive effect on network based devices with possibly hundreds of channels of which only
> a small number is used (e.g. record enabled) at a time.
> 
> The ringbuffer should be replaced by a buffer that holds the packets and a descriptor for how to find the data in it. Btw, alsa uses something similar already for the mmap handling.
> 
> The descriptor should consist of
> x periods, containing y chunks with a max size, containing z channels, each of the channel described by a start address and step value within that chunk.
> 
> Examples:
> PCI device; 2 periods, 1 chunks per period, max size 64 frames per chunk, 2 channels per chunk
> USB device: 2 periods, 8 chunks (microframes) max size 8 frames (if at 44.1/48kHz), 2 channels per chunk,
> Same for Firewire, AVB (each chunk possibly containing several AVB streams, i.e. ethernet packets), etc.
> 
> Period elapsed => the number of chunks forming a period have been received
> 
> snd_pcm_avail(_update) => return the sum of actual frames of the period
> 
> snd_pcm_mmap_commit => return the descriptor for one chunk, the number of frames of the chunk and a channel map for the chunk. The reason for the latter is that on ethernet based devices (AVB) there is bo guarantee that streams of different endpoints are received in the same order (but in the same interval window).
> Alsa clients should then loop until they have processed all frames thar have been reported by snd_pcm_avail (instead of a period size number of frames).
> 
> Ah, and AM824 raw audio format, used by firewire and AVB, should by added to the list of audio formats, so conversion can be done in userspace.

You can create a new mmap type for the ALSA API and add the support code to
the ALSA PCM kernel and ALSA library to optimize the data handling for this
"special" hardware cases. It just moves the sample layout conversion from the
driver to the user space (ALSA library).

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