Selectable async notification signal?

Selectable async notification signal?

[Stuffed Crust]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

How painful would it be to add an API call to set the async notification
signal to be something other than SIGIO?

I'm getting select()s blocking indefinately because of this.  While
changing a #define works for my local alsa-lib tree, it doesn't help
anyone who needs to use my code.

 - Pizza
-- 
Solomon Peachy                                    pizzaATfucktheusers.org
I ain't broke, but I'm badly bent.                           ICQ# 1318344
Patience comes to those who wait.
    ...It's not "Beanbag Love", it's a "Transanimate Relationship"...

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Selectable async notification signal?

[Takashi Iwai]

At Sun, 7 Apr 2002 23:45:48 -0400,
Stuffed Crust wrote:
> 
> How painful would it be to add an API call to set the async notification
> signal to be something other than SIGIO?
 
from alsa-lib/src/pcm.c:

/**
 * \brief set async mode
 * \param pcm PCM handle
 * \param sig Signal to raise: < 0 disable, 0 default (SIGIO)
 * \param pid Process ID to signal: 0 current
 * \return 0 on success otherwise a negative error code
 *
 * A signal is raised every period.
 */
int snd_pcm_async(snd_pcm_t *pcm, int sig, pid_t pid)

.. so you can pass your favorite signal to the 2nd argument.

or do i misunderstand your question?


Takashi

Re: Selectable async notification signal?

[Paul Davis]

>> How painful would it be to add an API call to set the async notification
>> signal to be something other than SIGIO?

[ explanation ]

and just remember not to actually do anything complicated from your
signal handler. ioctl(2), which is used for most ALSA user/kernel
space communication, is not async-safe, and thus cannot be used from a
signal handler without creating undefined behaviour. to quote from at
least one text:

      "In general, applications should do only the minimum possible
       in the handlers for asynchronous signals, such as setting a flag
       or posting a semaphore."

--p

Re: Selectable async notification signal?

[Stuffed Crust]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

On Thu, Apr 11, 2002 at 06:23:13PM +0200, Takashi Iwai wrote:
> int snd_pcm_async(snd_pcm_t *pcm, int sig, pid_t pid)
> 
> .. so you can pass your favorite signal to the 2nd argument.
> 
> or do i misunderstand your question?

Yes, let me try to explain it a bit better.

BTW, This is for FreeSCI (http://freesci.linuxgames.com).

The main process forks off a child to handle all of the sound-related
stuff, and communicates with that child through a pair of pipes.  We use
select()s to check for events, usually with a very small (~100ms max)
timeout.  We need the timeout to enforce note timing.

The child process is what opens the sound device.

I wrote an ALSA PCM output plugin for FreeSCI which uses async PCM; ie
I register a callback, and every period ALSA kicks in, executes the
callback and fills its buffers.

Both on their own work just fine.  However, when I turn on the ALSA
callback, the select()s block indefinately.   Since the select()s block,
no note data gets fired off, which results in no sound.

I am not installing any SIGIO handler at all; The only ones installed in
the child is SIGPIPE.

I tried the snd_pcm_async() call; that didn't help.  What
happens is the callback keeps kitting my custom signal, but meanwhile
the select()s still block.  

If I don't start the pcm device, then the select()s succeed.

 - Pizza
-- 
Solomon Peachy                                    pizzaATfucktheusers.org
I ain't broke, but I'm badly bent.                           ICQ# 1318344
Patience comes to those who wait.
    ...It's not "Beanbag Love", it's a "Transanimate Relationship"...

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]