PCM Ring Buffer - Revision history

Perex: /* Ring buffer & mmap versus OSS mmap */

2007-08-13T09:50:10Z

Ring buffer & mmap versus OSS mmap

← Older revision		Revision as of 09:50, 13 August 2007
Line 31:		Line 31:

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

Perex at 08:45, 13 August 2007

2007-08-13T08:45:48Z

← Older revision		Revision as of 08:45, 13 August 2007
Line 11:		Line 11:
	Non-Interleaved format is like this (C means channel sample):		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		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).		It's like separate mono buffers. Note that offsets of buffers might not be continuous (there might be a gap between channel areas).

Perex at 08:44, 13 August 2007

2007-08-13T08:44:57Z

← Older revision		Revision as of 08:44, 13 August 2007
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.

Perex at 06:26, 14 April 2007

2007-04-14T06:26:50Z

← Older revision		Revision as of 06:26, 14 April 2007
Line 10:		Line 10:
	* 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.

Perex at 06:23, 14 April 2007

2007-04-14T06:23:58Z

← Older revision		Revision as of 06:23, 14 April 2007
Line 1:		Line 1:

	== Ring buffer & mmap ==		== 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 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?

Perex at 06:22, 14 April 2007

2007-04-14T06:22:57Z

← Older revision		Revision as of 06:22, 14 April 2007
Line 1:		Line 1:
	Ring buffer & mmap
			== 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 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.

Perex: 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 ...

2007-04-14T06:22:41Z

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

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

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