[alsa-devel] dmix in a forked process
Don't know why the earlier message got truncated so here it is again...
Reading the source alsa-lib I see that dmix runs in a forked process *without* exec.
file: src/pcm/pcm_direct.c function: snd_pcm_direct_server_create
ret = fork(); if (ret < 0) { close(dmix->server_fd); return ret; } else if (ret == 0) { ret = fork(); if (ret == 0) server_job(dmix); _exit(EXIT_SUCCESS); } else { waitpid(ret, NULL, 0); }
_From what I understand, this is a concern since if our app is the first to start dmix then a copy of the process (app) will remain till the system is shutdown ?
Also I see that from alsa-lib 1.0.12 a check is performed before starting dmix.
file: src/pcm/pcm_dmix.c function: snd_pcm_dmix_open
if (dmix->shmptr->use_server) { dmix->server_free = dmix_server_free;
ret = snd_pcm_direct_server_create(dmix); if (ret < 0) { SNDERR("unable to create server"); goto _err; } }
When I checked how dmix->shmptr->use_server is set
file: src/pcm/pcm_dmix.c function: snd_pcm_direct_initialize_slave
int ver = 0; ioctl(spcm->poll_fd, SNDRV_PCM_IOCTL_PVERSION, &ver); if (ver < SNDRV_PROTOCOL_VERSION(2, 0, 8)) dmix->shmptr->use_server = 1;
So if sndrv version is older than 2.0.8, use_server is set!
So even using alsa-lib greater than 1.0.12 doesn't guarantee that the forked process (without exec) code path will be avoided.
I'm currently porting the sound code of our app from OSS to ALSA but this problem is preventing me from doing so. Is there any way to get around this problem?
Help here will be greatly appreciated.
If this is an incorrect list then kindly fwd it to the appropriate one.
Thanks, Bankim.
PS: I've tried using the ioctl mentioned above after copying the necessary macros from kernel headers but ioctl returns error "Inappropriate ioctl for this device" on my Ubuntu 7.04 host.
On Sat, 2 Aug 2008, Bankim Bhavsar wrote:
I'm currently porting the sound code of our app from OSS to ALSA but this problem is preventing me from doing so. Is there any way to get around this problem?
What's your problem with fork()? I don't see the reason, why fork should be avoided. The server_job() process ends when the last application closes shared device. It's just management task to manage and release resources shared among audio processes.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Sun, Aug 3, 2008 at 11:38 AM, Jaroslav Kysela perex@perex.cz wrote:
On Sat, 2 Aug 2008, Bankim Bhavsar wrote:
I'm currently porting the sound code of our app from OSS to ALSA but this problem is preventing me from doing so. Is there any way to get around this problem?
What's your problem with fork()?
If our app is the first to start dmix then a copy of the process (app) will remain till the last application closes the share device.
So our problem is not fork but fork without *exec*.
Thanks, Bankim.
At Sun, 3 Aug 2008 13:47:34 -0700, Bankim Bhavsar wrote:
On Sun, Aug 3, 2008 at 11:38 AM, Jaroslav Kysela perex@perex.cz wrote:
On Sat, 2 Aug 2008, Bankim Bhavsar wrote:
I'm currently porting the sound code of our app from OSS to ALSA but this problem is preventing me from doing so. Is there any way to get around this problem?
What's your problem with fork()?
If our app is the first to start dmix then a copy of the process (app) will remain till the last application closes the share device.
Right. At least, its resources remain.
So our problem is not fork but fork without *exec*.
And what is your problem more exactly?
We may create a small binary to do exec for the dmix server if this really matters. Or, an easier fix is to use more recent kernels. Then there is no longer fork for dmix.
Takashi
Thanks for the reply Takashi. Comments inline.
I'm currently porting the sound code of our app from OSS to ALSA but this problem is preventing me from doing so. Is there any way to get around this problem?
What's your problem with fork()?
If our app is the first to start dmix then a copy of the process (app) will remain till the last application closes the shared device.
Right. At least, its resources remain.
Yes this a concern.
So our problem is not fork but fork without *exec*.
And what is your problem more exactly?
We may create a small binary to do exec for the dmix server if this really matters.
Yes this is something we are looking for and will be a great enhancement in the future release of alsa-lib :)
Or, an easier fix is to use more recent kernels. Then there is no longer fork for dmix.
Agreed and thats why we were planning to use the ioctl to determine the sound drv version but somehow ioctl returns failure and not something we would want to rely on. ioctl(spcm->poll_fd, SNDRV_PCM_IOCTL_PVERSION, &ver);
Also our product VMware workstation is supported on wide range of Linux operating systems and so we don't want to restrict with snd drv version > 2.0.8
Thanks, Bankim.
participants (3)
-
Bankim Bhavsar
-
Jaroslav Kysela
-
Takashi Iwai