public-hk wrote:
I have understood from the docs that the snd_pcm_read/snd_pcm_write functions do nothing else than addressing the memory mapped areas. As a conclusion, I realize this access myself to have more control about it.
Why do you want to duplicate snd_pcm_read/write? What do you "control" there, i.e., what are you doing differently?
The additional degree of freedom is that I see the amount of samples which are available in the mmap'ed buffer whereas with read and write, I only get the notification that a specific amount of samples has been available (based on the number of samples to be read/written specified when calling the function).
snd_pcm_avail()
And by using the async callbacks, I do not have to deal with blocking or non-blocking read functions or polling related issues.
But instead you have to deal with signal delivery. Besides being nonportable, you are not allowed to do anything useful inside a signal handler.
Why is this nonportable?
Not every sound device type supports async callbacks.
The sound APIs that I dealt with before more or less by definition work based on callback mechanisms (ASIO, CoreAudio). What is the restriction considering the processing that I plan within the signal handler?
Signals are _not_ threads; they are sent to an existing process or thread, and interrupt it.
Most functions are not reentrant and therefore cannot be called from a signal handler. The only useful thing you _can_ do is to write to a pipe to wake up another thread that waits with poll() for this notification, but then you could just as well wait for the device itself.
Is that a documented restriction?
http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
(ALSA uses SIGIO. SIGEV_THREAD is not supported.)
A possible alternative realization would be to start a thread in which I do
- pcm_read
- process audio samples
- pcm_write
in an infinite loop. In this case, however, the "read" would also block the "write" for a specific time. This architecture would a) introduce additional delay if I miss the next required "write" due to the blocking "read". b) might reduce the available processing time (operation "process audio samples") since I have "wasted" time in the blocking "read".
Then use non-blocking mode. (Or use a library that does this for you.)
Regards, Clemens