Difference between revisions of "PCM Ring Buffer"

From AlsaProject
Jump to: navigation, search
(New page: Ring buffer & 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 ...)
 
(Ring buffer & mmap versus OSS mmap)
 
(5 intermediate revisions by one user not shown)
Line 1: Line 1:
Ring buffer & mmap
+
==Ring buffer organization==
 +
 
 +
===Interleaved access===
 +
 
 +
Interleaved format is like this (C means channel sample):
 +
 
 +
  C0 C1 C2 C3 C0 C1 C2 C3 ....
 +
 
 +
===Non-Interleaved access===
 +
 
 +
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).
 +
 
 +
===Complex access===
 +
 
 +
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.
 
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. 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).
+
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?
 
'''What tries OSS API to do? Is the behaviour when application receives direct pointer to mmap sample area and actual hardware sample position better?
Line 10: Line 30:
 
* 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.
 
* 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 will 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.
+
* 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.
 +
 
 +
* This setup will have trouble with the ALSA resampler (expecting and transferring only whole period) and dmix (the rewind operation is not supported at this moment).

Latest revision as of 11:50, 13 August 2007

Contents

[edit] Ring buffer organization

[edit] Interleaved access

Interleaved format is like this (C means channel sample):

 C0 C1 C2 C3 C0 C1 C2 C3 ....

[edit] Non-Interleaved access

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).

[edit] Complex access

More complex access. For example with gaps between channels etc. ALSA API limits this access to have fixed spacing between samples for one channel.

[edit] 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.
  • This setup will have trouble with the ALSA resampler (expecting and transferring only whole period) and dmix (the rewind operation is not supported at this moment).
Custom Search
Personal tools
Namespaces

Variants
Actions
Navigation
wiki
Toolbox