Re: Some questions related to ALSA based duplex audio processing

[Clemens Ladisch <clemens@ladisch.de>]

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
> 1) pcm_read
> 2) process audio samples
> 3) 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