Third time: Unlink PCM resource ?

Third time: Unlink PCM resource ?

[Werner Van Belle]

[-- Attachment #1.1: Type: text/plain, Size: 1448 bytes --]

Hello,

This is the third time I tried to get information on the same topic but
there has been no response. Since it is crucial for me to get this to
work, I really would appreciate your input. If necssary I can provide
further documentation. The problem is as follows: if a process which
opened a DSP device forks of a new process, then this child will have
the same handle towards the DSP. What I now want to do is to release the
handle in the child without closing the device for the parent as well.
So essentially the sequence below illustrates the problem if one is
unable to 'unlink' a dsp device.

a- parent process creates and open dsp device
b- parent process forks of a child 1. Child 1 has access to the same dsp
device
c- parent process closes the DSP device
d- client process can no longer write to the DSP device (these are
already odd semantics, but okay, can live with it)
e- parent process forks of a second child. Child 2 has no dsp device
f- Child 2 tries to open the DSP device. This fails because the device,
although closed, is not released yet by Child 1.

Is this normal behavior ?
Is there some rigid documentation on the closing and sharing semantics
of pcm devices ?
Is there a way to unlink a device without closing it ?

If this is the wrong mailinglist, then who should I contact regarding
these erratic semantics ?

Wkr,

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Third time: Unlink PCM resource ?

[Takashi Iwai]

At Mon, 25 May 2009 17:30:19 +0200,
Werner Van Belle wrote:
>
> Hello,
> 
> This is the third time I tried to get information on the same topic but
> there has been no response. Since it is crucial for me to get this to
> work, I really would appreciate your input. If necssary I can provide
> further documentation. The problem is as follows: if a process which
> opened a DSP device forks of a new process, then this child will have
> the same handle towards the DSP. What I now want to do is to release the
> handle in the child without closing the device for the parent as well.
> So essentially the sequence below illustrates the problem if one is
> unable to 'unlink' a dsp device.
> 
> a- parent process creates and open dsp device
> b- parent process forks of a child 1. Child 1 has access to the same dsp
> device
> c- parent process closes the DSP device
> d- client process can no longer write to the DSP device (these are
> already odd semantics, but okay, can live with it)
> e- parent process forks of a second child. Child 2 has no dsp device
> f- Child 2 tries to open the DSP device. This fails because the device,
> although closed, is not released yet by Child 1.
> 
> Is this normal behavior ?
> 
> Is there some rigid documentation on the closing and sharing semantics
> of pcm devices ?
> Is there a way to unlink a device without closing it ?

Unlikely.

> If this is the wrong mailinglist, then who should I contact regarding
> these erratic semantics ?

Which API are you using?  A simple test case code would be more
helpful to demonstrate.

But, in general, sharing the same DSP device among different processes
don't sound like a good idea...


Takashi

Re: Third time: Unlink PCM resource ?

[Werner Van Belle]

[-- Attachment #1.1: Type: text/plain, Size: 776 bytes --]

Takashi Iwai wrote:
>> If this is the wrong mailinglist, then who should I contact regarding
>> these erratic semantics ?
>>     
>
> Which API are you using?  A simple test case code would be more
> helpful to demonstrate.
>   
The api provided by libasound. I'll see whether I can generate a concise
example if there is no known solution to this problem,
> But, in general, sharing the same DSP device among different processes
> don't sound like a good idea...
>   

I agree, but when one forks off a child the parent pcm handle
automatically passes to the child. If there is a possibility _not_ to
pass the PCM handle to the forked process then I would be quite happy as
well.

Werner,-

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Third time: Unlink PCM resource ?

[Jaroslav Kysela]

On Mon, 25 May 2009, Werner Van Belle wrote:

> I agree, but when one forks off a child the parent pcm handle
> automatically passes to the child. If there is a possibility _not_ to
> pass the PCM handle to the forked process then I would be quite happy as
> well.

Do you call close() for all opened file descriptors associated to 
snd_pcm_t handle in child process?

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Third time: Unlink PCM resource ?

[Werner Van Belle]

[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]

Jaroslav Kysela wrote:
> Do you call close() for all opened file descriptors associated to 
> snd_pcm_t handle in child process?
>   
I use snd_pcm_close() in the child process, but this will also close the
parent process its pcm device, which is clearly not wanted.

Wkr,

Werner,-

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Third time: Unlink PCM resource ?

[Takashi Iwai]

At Mon, 25 May 2009 19:52:47 +0200,
Werner Van Belle wrote:
> 
> > But, in general, sharing the same DSP device among different processes
> > don't sound like a good idea...
> >   
> 
> I agree, but when one forks off a child the parent pcm handle
> automatically passes to the child. If there is a possibility _not_ to
> pass the PCM handle to the forked process then I would be quite happy as
> well.

You can control it via fcntl().  See fcntl(2) man page.


Takashi

Re: Third time: Unlink PCM resource ?

[Werner Van Belle]

[-- Attachment #1.1: Type: text/plain, Size: 541 bytes --]

Takashi Iwai wrote:
> You can control it via fcntl().  See fcntl(2) man page.
>   
I looked at that but I didn't find any place in alsalib (or libalsa
whatever the order of those two words), where I can obtain the file
handle. They are all of type pcm_something_t. I found a file handle
quite deep in this library but there seems no way to actually obtain
that handle.

Do you think fcntl on a pcm_t device would work (if we got it to compile
first :-)

Werner,-

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Third time: Unlink PCM resource ?

[Jaroslav Kysela]

On Mon, 25 May 2009, Werner Van Belle wrote:

> Takashi Iwai wrote:
>> You can control it via fcntl().  See fcntl(2) man page.
>>
> I looked at that but I didn't find any place in alsalib (or libalsa
> whatever the order of those two words), where I can obtain the file
> handle. They are all of type pcm_something_t. I found a file handle
> quite deep in this library but there seems no way to actually obtain
> that handle.
>
> Do you think fcntl on a pcm_t device would work (if we got it to compile
> first :-)

snd_pcm_poll_descriptors / snd_pcm_poll_descriptors_count

But I wonder why snd_pcm_close() does not work in child process. Could you 
show us 'strace -f -e trace=open,close' for your program?

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Third time: Unlink PCM resource ?

[Takashi Iwai]

At Mon, 25 May 2009 20:31:42 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Mon, 25 May 2009, Werner Van Belle wrote:
> 
> > Takashi Iwai wrote:
> >> You can control it via fcntl().  See fcntl(2) man page.
> >>
> > I looked at that but I didn't find any place in alsalib (or libalsa
> > whatever the order of those two words), where I can obtain the file
> > handle. They are all of type pcm_something_t. I found a file handle
> > quite deep in this library but there seems no way to actually obtain
> > that handle.
> >
> > Do you think fcntl on a pcm_t device would work (if we got it to compile
> > first :-)
> 
> snd_pcm_poll_descriptors / snd_pcm_poll_descriptors_count

... which doesn't return always all used fd's.

> But I wonder why snd_pcm_close() does not work in child process. Could you 
> show us 'strace -f -e trace=open,close' for your program?

Passing O_CLOEXEC would be the best solution, I think.
We just need a few additions.


Takashi

Re: Third time: Unlink PCM resource ?

[Takashi Iwai]

At Mon, 25 May 2009 20:27:14 +0200,
Werner Van Belle wrote:
> 
> Takashi Iwai wrote:
> > You can control it via fcntl().  See fcntl(2) man page.
> >   
> I looked at that but I didn't find any place in alsalib (or libalsa
> whatever the order of those two words), where I can obtain the file
> handle. They are all of type pcm_something_t. I found a file handle
> quite deep in this library but there seems no way to actually obtain
> that handle.

OK, I see the problem now, too.  In practice, you can get a file
descriptor from poll descriptor, but this doesn't cover all underlying
fds.  A new API function or an additional SND_PCM_* flag for
snd_pcm_open() would be needed, indeed.

In the latter case, it must be easy -- just pass O_CLOEXEC flag to
open() call...


Takashi

Re: Third time: Unlink PCM resource ?

[Jaroslav Kysela]

On Mon, 25 May 2009, Takashi Iwai wrote:

> At Mon, 25 May 2009 20:27:14 +0200,
> Werner Van Belle wrote:
>>
>> Takashi Iwai wrote:
>>> You can control it via fcntl().  See fcntl(2) man page.
>>>
>> I looked at that but I didn't find any place in alsalib (or libalsa
>> whatever the order of those two words), where I can obtain the file
>> handle. They are all of type pcm_something_t. I found a file handle
>> quite deep in this library but there seems no way to actually obtain
>> that handle.
>
> OK, I see the problem now, too.  In practice, you can get a file
> descriptor from poll descriptor, but this doesn't cover all underlying
> fds.  A new API function or an additional SND_PCM_* flag for
> snd_pcm_open() would be needed, indeed.

The question is if it's not better to free also allocated memory 
associated to the pcm handle in child process - so snd_pcm_close() 
call in child is not a bad idea.

 					Jaroslav
-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Third time: Unlink PCM resource ?

[Werner Van Belle]

[-- Attachment #1.1.1: Type: text/plain, Size: 1398 bytes --]

Jaroslav Kysela wrote:
> The question is if it's not better to free also allocated memory 
> associated to the pcm handle in child process - so snd_pcm_close() 
> call in child is not a bad idea.
>   
Okay, while you both have been discussing some internals, which I didn't
try yet, I created a demonstration program to illustrate the mixed
semantics of the 'sharing' versus 'not sharing' behavior of the dsp
devices. In the example the parent thread will play a sound, then the
child closes the dsp, which affects the playback in the parent (it
either hangs or skips all remaining samples). From this one would
conclude that the pcm device is fully shared between the two processes
(semantics I can live with). However, when the parent then tries to
reopen the device it cannot do so because the device is still 'busy'.

As a solution, a call to an unlink function would maybe solve it but it
is indicative of a deeper unclarity of how the semantics of shared DSP
devices should be. I would propose to let alsa act as a true filehandle.
In such a scenario a close in the child should not affect the playback
in the parent since the parent still has the descriptor open. Please
have a look at the attached code. It is 256 lines :-) The problem is
documented in the main routine.

With kind regards,

Werner,-

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: close-affects-play.cpp --]
[-- Type: text/x-c++src; name="close-affects-play.cpp", Size: 6736 bytes --]

using namespace std;
#include <math.h>
#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define ALSA_PCM_NEW_HW_PARAMS_API
#define ALSA_PCM_NEW_SW_PARAMS_API
#include <stdarg.h>
#include <alsa/asoundlib.h>
#include "memory.h"
#include <iostream>

typedef unsigned int unsigned4;
typedef signed long long signed8;
typedef signed short signed2;
snd_pcm_t *dsp;
snd_pcm_uframes_t buffer_size;
snd_pcm_uframes_t period_size;
unsigned4 * buffer;
unsigned4 filled;
int        arg_latency;
char *     arg_dev;
const int err_dsp=1;
const int err_none=0;

void Info(const char* script, ...)
{
  char toexecute[1024];
  va_list ap;
  va_start(ap,script);
  vsnprintf(toexecute,1024,script,ap);
  va_end(ap);
  cout << toexecute << '\n';
  fflush(stdout);
};

void dsp_write(unsigned4 *value)
{
  int err = 0;
  while(!err)
    {
      err = snd_pcm_writei(dsp,value,1);
    }
  assert(err!=-EAGAIN);
  assert(err!=-ESTRPIPE);
  if (err==-EPIPE)
    {
      Info("underrun occured...");
      err = snd_pcm_prepare(dsp);
      if (err < 0)
	Info("cant recover from underrun: %s",snd_strerror(err));
      return;
    }
}

int dsp_open()
{
  int err;
  unsigned int buffer_time, period_time;
  snd_pcm_hw_params_t *hparams;
  snd_pcm_sw_params_t *sparams;
  snd_output_t * output = NULL;
  err = snd_output_stdio_attach(&output,stdout,0);
  if (err < 0 )
    {
      Info("attaching to stdio didn't succeed: %s",snd_strerror(err));
      return err_dsp;
    }
  err = snd_pcm_open(&dsp, arg_dev, SND_PCM_STREAM_PLAYBACK, 0);
  if (err < 0)
    {
      Info("opening alsa device failed : %s",snd_strerror(err));
      return err_dsp;
    }
  
  snd_pcm_sw_params_alloca(&sparams);
  snd_pcm_hw_params_alloca(&hparams);
  
  err = snd_pcm_hw_params_any(dsp, hparams);
  if (err<0)
    {
      Info("Broken configuration file for pcm : %s",snd_strerror(err));
      return err_dsp;
    }  
  err = snd_pcm_hw_params_set_access(dsp, hparams, SND_PCM_ACCESS_RW_INTERLEAVED);
  if (err<0)
    {
      Info("Unable to set interleaved access to pcm device: %s",snd_strerror(err));
      return err_dsp;
    }
  err = snd_pcm_hw_params_set_format(dsp, hparams, SND_PCM_FORMAT_S16);
  if (err<0)
    {
      Info("Unable to set sample format to standard 16 bit: %s",snd_strerror(err));
      return err_dsp;
    }
  err = snd_pcm_hw_params_set_channels(dsp, hparams, 2);
  if (err < 0)
    {
      Info("setting dsp to 2 channels failed : %s",snd_strerror(err));
      return err_dsp;
    }
  
  unsigned int q = 44100;
  err = snd_pcm_hw_params_set_rate_near(dsp, hparams, &q, 0);
  if (err < 0)
    {
      Info("setting dsp speed (%d) failed",q);
      return err_dsp;
    }
  if (q != 44100)
    Info("setting dsp speed (%d) failed, resulting rate = %d ",44100, q);

  period_time = arg_latency * 1000;
  buffer_time = period_time *2;
  {
    unsigned int t = buffer_time;
    int dir = 1;
    err = snd_pcm_hw_params_set_buffer_time_near(dsp,hparams,&t,&dir);
    if (err<0)
      {
	Info("dsp-alsa: Impossible to set pcm buffer time to %i (%i): %s", buffer_time,t,snd_strerror(err));
	return err_dsp;
      }
    
    err = snd_pcm_hw_params_get_buffer_size(hparams,&buffer_size);
    if (err<0)
      {
	Info("     impossible to obtain buffer size: %s",snd_strerror(err));
	return err_dsp;
      }
    
    t = period_time;
    err = snd_pcm_hw_params_set_period_time_near(dsp, hparams,&t,&dir);
    if (err<0)
      {
	Info("     impossible to set pcm period time to %i (%i): %s", period_time,t,snd_strerror(err));
	return err_dsp;
      }
    err = snd_pcm_hw_params_get_period_size(hparams,&period_size,&dir);
    if (err<0)
      {
	Info("     ompossible to obtain period data size: %s",snd_strerror(err));
	return err_dsp;
      }
    if (period_size*2 - 1>buffer_size)
      {
	Info("The alsa driver cannot allocate sufficiently large buffers due to the "
	      "large requested latency. (playbuffer size   = %li, "
	      "total buffer size = %li). Try decreasing the latency.",period_size,buffer_size);
	return err_dsp;
      }
    dir = 0;
  }
  err = snd_pcm_hw_params(dsp,hparams);
  if (err < 0)
    {
      Info("unable to set hw parameters for pcm: %s",snd_strerror(err));
      return err_dsp;
    }
  
  err = snd_pcm_sw_params_current(dsp,sparams);
  if (err < 0)
    {
      Info("unable to determine sw parameters for pcm: %s",snd_strerror(err));
      return err_dsp;
    } 
  err = snd_pcm_sw_params_set_start_threshold(dsp,sparams,buffer_size);
  if (err < 0)
    {
      Info("unable to set start to treshold mode: %s",snd_strerror(err));
      return err_dsp;
    }
  err = snd_pcm_sw_params_set_avail_min(dsp,sparams,period_size);
  if (err < 0 )
    {
      Info("unable to set minimum start size: %s",snd_strerror(err));
      return err_dsp;
    }
  err = snd_pcm_sw_params(dsp,sparams);
  if (err < 0)
    {
      Info("unable to set software parameters: %s",snd_strerror(err));
      return err_dsp;
    }
  snd_pcm_dump(dsp,output);
  buffer = (unsigned4*)malloc(period_size*sizeof(unsigned4));
  return err_none;
}

void dsp_close()
{
  int err = snd_pcm_close(dsp);
  if (err < 0)
    Info("cant close pcm device: %s",snd_strerror(err));
  dsp=0;
}

void stream_wave()
{
  for(int t=10; t>=0; t--)
    {
      cerr << "Parent plays (" << t << "s left)\n";
      for(int i = 0 ; i < 44100; i++)
	{
	  float x=i;
	  float y=16384.*sin(x*2*M_PI*220./44100.)/4;
	  struct {signed2 l; signed2 r;} lr;
	  lr.l=y;
	  lr.r=y;
	  dsp_write((unsigned4*)&lr);
	}
    }
}

/**
 * This example first shows that a close in the child will 
 * affect the playback in the parent. Sometimes the parents
 * just hangs in the write call, sometimes it just skips
 * all samples.
 * 
 * However, the device in the parent is actually not 
 * closed at all since we cannot reopen it.
 */
int main (int argc, char* argv[])
{
  arg_dev = "hw:0";
  dsp = NULL;
  filled = 0;
  buffer_size = 0;
  period_size = 0;
  arg_latency = 150;
  // first open the DSP device.
  Info("Opening DSP Device in parent thread");
  dsp_open();
  int childpid=fork(); assert(childpid>-1);
  if (childpid)
    {
      // the parent thread now waits two seconds and the closes the device
      Info("Parent thread playing");
      stream_wave();
      Info("Parent tries to reopen the device");
      dsp_open();
      stream_wave();
    }
  else
    {
      sleep(5);
      Info("Child closes the dsp device");
      dsp_close();
    }
}

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Third time: Unlink PCM resource ?

[Jaroslav Kysela]

On Mon, 25 May 2009, Werner Van Belle wrote:

> Jaroslav Kysela wrote:
>> The question is if it's not better to free also allocated memory
>> associated to the pcm handle in child process - so snd_pcm_close()
>> call in child is not a bad idea.
>>
> Okay, while you both have been discussing some internals, which I didn't
> try yet, I created a demonstration program to illustrate the mixed
> semantics of the 'sharing' versus 'not sharing' behavior of the dsp
> devices. In the example the parent thread will play a sound, then the
> child closes the dsp, which affects the playback in the parent (it
> either hangs or skips all remaining samples). From this one would
> conclude that the pcm device is fully shared between the two processes
> (semantics I can live with). However, when the parent then tries to
> reopen the device it cannot do so because the device is still 'busy'.

Your example program does not contain dsp_close() call in parent before 
dsp_open(). That's reason why PCM device is blocked.

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Third time: Unlink PCM resource ?

[Werner Van Belle]

[-- Attachment #1.1: Type: text/plain, Size: 455 bytes --]

Jaroslav Kysela wrote:
> Your example program does not contain dsp_close() call in parent before 
> dsp_open(). That's reason why PCM device is blocked.
>   
That could make sense, but then the wave should not stop playing when
the child process closes the dsp ?
Currently the child process has no way to release the dsp without
stopping the parent process during play.

Werner,-

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Third time: Unlink PCM resource ?

[Takashi Iwai]

At Mon, 25 May 2009 20:39:45 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Mon, 25 May 2009, Takashi Iwai wrote:
> 
> > At Mon, 25 May 2009 20:27:14 +0200,
> > Werner Van Belle wrote:
> >>
> >> Takashi Iwai wrote:
> >>> You can control it via fcntl().  See fcntl(2) man page.
> >>>
> >> I looked at that but I didn't find any place in alsalib (or libalsa
> >> whatever the order of those two words), where I can obtain the file
> >> handle. They are all of type pcm_something_t. I found a file handle
> >> quite deep in this library but there seems no way to actually obtain
> >> that handle.
> >
> > OK, I see the problem now, too.  In practice, you can get a file
> > descriptor from poll descriptor, but this doesn't cover all underlying
> > fds.  A new API function or an additional SND_PCM_* flag for
> > snd_pcm_open() would be needed, indeed.
> 
> The question is if it's not better to free also allocated memory 
> associated to the pcm handle in child process - so snd_pcm_close() 
> call in child is not a bad idea.

OK, in a case without exec, we need an explicit call.
But I guess snd_pcm_close() isn't appropriate (as Werner experienced)
since it calls snd_pcm_drop() there.  I guess this call isn't needed
as the driver itself takes care?


Takashi

Re: Third time: Unlink PCM resource ?

[Werner Van Belle]

[-- Attachment #1.1: Type: text/plain, Size: 611 bytes --]

Takashi Iwai wrote:
> OK, in a case without exec, we need an explicit call.
> But I guess snd_pcm_close() isn't appropriate (as Werner experienced)
> since it calls snd_pcm_drop() there.  I guess this call isn't needed
> as the driver itself takes care?
>   
You mean: modifying the snd_pcm_close routine to not call snd_pcm_drop ?
I guess that might work as well to solve my problem.
Will such a fix appear in a new alsa release ?

I'd like to thank you for the time you spent to look at this issue.

With kind regards,

Werner,-

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Third time: Unlink PCM resource ?

[Takashi Iwai]

At Tue, 26 May 2009 10:14:56 +0200,
Werner Van Belle wrote:
> 
> Takashi Iwai wrote:
> > OK, in a case without exec, we need an explicit call.
> > But I guess snd_pcm_close() isn't appropriate (as Werner experienced)
> > since it calls snd_pcm_drop() there.  I guess this call isn't needed
> > as the driver itself takes care?
> >   
> You mean: modifying the snd_pcm_close routine to not call snd_pcm_drop ?

Yes.

> I guess that might work as well to solve my problem.
> Will such a fix appear in a new alsa release ?

We need more tests :)  I might overlook something.


Takashi

Re: Third time: Unlink PCM resource ?

[Takashi Iwai]

At Tue, 26 May 2009 10:17:41 +0200,
I wrote:
> 
> At Tue, 26 May 2009 10:14:56 +0200,
> Werner Van Belle wrote:
> > 
> > Takashi Iwai wrote:
> > > OK, in a case without exec, we need an explicit call.
> > > But I guess snd_pcm_close() isn't appropriate (as Werner experienced)
> > > since it calls snd_pcm_drop() there.  I guess this call isn't needed
> > > as the driver itself takes care?
> > >   
> > You mean: modifying the snd_pcm_close routine to not call snd_pcm_drop ?
> 
> Yes.
> 
> > I guess that might work as well to solve my problem.
> > Will such a fix appear in a new alsa release ?
> 
> We need more tests :)  I might overlook something.

Finally had some time to take a look at this pending issue...

Through tests, I found that this can be really a problem, too.
The below is a quick fix, adding a new function, snd_pcm_detach().
This works like snd_pcm_close() but without stopping it.  Give it a
try.

If anyone sees a problem with it, let me know.


thanks,

Takashi

---
>From bdbce35b6d582d4ee4a0813190f09232bd8dc02c Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 7 Jul 2009 16:59:09 +0200
Subject: [PATCH] Add snd_pcm_detach() function

Added a new function, snd_pcm_detach().
This function closes the given PCM stream without stopping.
It's useful for closing the inherited PCM stream after forking
without interfering the parent process.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 include/pcm.h |    1 +
 src/pcm/pcm.c |   16 ++++++++++++++++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/include/pcm.h b/include/pcm.h
index 15e9cb2..9992d53 100644
--- a/include/pcm.h
+++ b/include/pcm.h
@@ -412,6 +412,7 @@ int snd_pcm_open_lconf(snd_pcm_t **pcm, const char *name,
 		       snd_config_t *lconf);
 
 int snd_pcm_close(snd_pcm_t *pcm);
+int snd_pcm_detach(snd_pcm_t *pcm);
 const char *snd_pcm_name(snd_pcm_t *pcm);
 snd_pcm_type_t snd_pcm_type(snd_pcm_t *pcm);
 snd_pcm_stream_t snd_pcm_stream(snd_pcm_t *pcm);
diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
index e63bbe9..059840f 100644
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -713,6 +713,22 @@ int snd_pcm_close(snd_pcm_t *pcm)
 }	
 
 /**
+ * \brief close PCM handle without stopping the assigned stream
+ * \param pcm PCM handle
+ * \return 0 on success otherwise a negative error code
+ *
+ * Closes the specified PCM handle without stopping the stream.
+ * This can be useful if you need to close and release the inherited
+ * PCM stream after forking.  Unlike snd_pcm_stop(), this function
+ * doesn't influence the PCM stream of the parent.
+ */
+int snd_pcm_detach(snd_pcm_t *pcm)
+{
+	pcm->donot_close = 1;
+	return snd_pcm_close(pcm);
+}
+
+/**
  * \brief set nonblock mode
  * \param pcm PCM handle
  * \param nonblock 0 = block, 1 = nonblock mode
-- 
1.6.3.2

Re: Third time: Unlink PCM resource ?

[Werner Van Belle]

[-- Attachment #1.1: Type: text/plain, Size: 592 bytes --]

Takashi Iwai wrote:
> OK, I see the problem now, too.  In practice, you can get a file
> descriptor from poll descriptor, but this doesn't cover all underlying
> fds.  A new API function or an additional SND_PCM_* flag for
> snd_pcm_open() would be needed, indeed.
>
> In the latter case, it must be easy -- just pass O_CLOEXEC flag to
> open() call...
>   
That handles the close on exec well, but we are talking about forks
here. There is not necessarily an exec involved in the child process.

Wkr,

Werner,-

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel