PCM Ring Buffer
Ring buffer organization
Interleaved format is like this (C means channel sample):
C0 C1 C2 C3 C0 C1 C2 C3 ....
Non-Interleaved format is like this (C means channel sample):
C0 C0 C0 C0 ................ C1 C1 C1 C1 ............. C2 C2 C2 C2 ............... C3 C3 C3 C3
It's like separate mono buffers. Note that offsets of buffers might not be continuous (there might be a gap between channel areas).
More complex access. For example with gaps between channels etc. ALSA API limits this access to have fixed spacing between samples for one channel.
Ring buffer & mmap versus OSS mmap
Comparing to OSS API, ALSA API has inteligent ring buffer management for the mmaped access. Application must start snd_pcm_mmap_begin() to obtain the location where to store / get samples to / from and when work is finished with given sample region, snd_pcm_mmap_commit() must be called to move sample pointers in the ring buffer.
There is a reason for this behaviour, the plugins (sample, rate conversion) which takes care about sample processing, must know about transferred samples and above functions control the data movement. Application might use snd_pcm_rewind() and snd_pcm_forward() functions to maintain position in the ring buffer itself, but it is not very recommended behaviour. Some ALSA plugins does not support these functions (mostly because they are not required for most of applications).
What tries OSS API to do? Is the behaviour when application receives direct pointer to mmap sample area and actual hardware sample position better?
- ALSA API can do also this behaviour. Simply eliminate stream stop after a threshold (set stop_threshold parameter to ring buffer boundary). In this case, application may check snd_pcm_status_get_delay() if application is behind ring buffer (negative value) and use snd_pcm_forward() to correct the ring buffer position.
- But think about it.. The standard applications should use fixed latency. If something goes wrong, it would results with crack or sound distortions mostly bad to humar ears. Is not better to use higher latency in this case, than trying to "fix" this problem with unpredictable ring buffer behaviour trying to use flying positions? It's like shooting to a running target.