0

I wrote a simple C++ wrapper representing an AudioStream based on ALSA API. It seems to me very convenient to use the async mode. Unfortunately, the callback function registered for async mode doesn't get invoked.

The alsa documentation states for snd_async_add_handler():

This function associates the callback function with the given file, and saves this association in a snd_async_handler_t object. Whenever the SIGIO signal is raised for the file fd, the callback function will be called with its parameter pointing to the async handler object returned by this function. The ALSA sigaction handler for the SIGIO signal automatically multiplexes the notifications to the registered async callbacks. However, the application is responsible for instructing the device driver to generate the SIGIO signal. The SIGIO signal may have been replaced with another signal, see snd_async_handler_get_signo.

Especially the bold part is interesting. Does that mean, that the user has to somehow configure the driver to generate those SIGIO's? I guess the SIGIO is just some sort of interrupt, so one has to enable interrupt generation by the driver??? I would expect this to be responsibility of ALSA through the hw_params configuration or so.

The only thing I was able to find was in the following link, where the answer states, that ASYNC is deprecated, however, from the ALSA documentation this doesn't seem to be true.

ALSA - managing async IO

ALSA documentation for reference: https://www.alsa-project.org/alsa-doc/alsa-lib/group___global.html#gafd936c40505997bb659b74bd368636b8

ST Renegade
  • 311
  • 3
  • 14

1 Answers1

0

snd_async_add_pcm_handler() is a wrapper for snd_async_add_handler() and automatically enables the signal.

And you should not specify SND_PCM_ASYNC in the snd_pcm_open() call.

And you must use a device that actually supports generating signals.

And your signal handler must not use any functions except for those in the list of async-signal-safe functions.

CL.
  • 173,858
  • 17
  • 217
  • 259
  • Thanks for the answer. So what is the point of SNC_PCM_ASYNC and the "mode" parameter in snd_pcm_open() function, when the parameter is set to 0 always? This is a bit confusing. I'm on embedded device, so I assume a device can be also understood the peripheral responsible for audio - DAI or so, right? – ST Renegade Feb 19 '20 at 08:35
  • I've also tried to read out the number of available frames via snd_pcm_avail_update in an infinite loop - as the asyn callback is not running - and I'm getting always 0 as a result. I would expect to get some reasonable value... – ST Renegade Feb 19 '20 at 09:26