[alsa-devel] Third time: Unlink PCM resource ?

[Werner Van Belle]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: close-affects-play.cpp
Type: text/x-c++src
Size: 6481 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20090525/8bbe85ee/attachment.cpp 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20090525/8bbe85ee/attachment.sig