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?

Revision as of 08:23, 14 April 2007

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