Fix dup for /dev/dsp
Pierre A. Humblet
Thu Jul 22 03:29:00 GMT 2004
At 01:00 PM 7/21/2004 -0400, Christopher Faylor wrote:
>On Wed, Jul 21, 2004 at 11:12:22AM -0400, Pierre A. Humblet wrote:
>>Here is another idea.
>>As noted in your comments, the children cannot change any of the
>>parameters (because they don't have access to the parent). To fix that
>>I am wondering if it wouldn't be better to use a FileMapping that can
>>be shared between parent and children, instead of an archetype.
>>Apparently that's what fhandler_tape does. See mtinfo_init () in
>>fhandler_tape.cc Perhaps that share can be created on demand when the
>>dsp is opened, instead of creating it for every process as tape does.
>>My understanding is very superficial, I apologize in advance if I
>If this is all that's required, you could use an __attribute__((shared))
>option to share the state among all processes.
That would work too, I think, although it's not secure.
But there is a complication. Apparently a PC can have several input and
output audio devices and I don't see why several of them couldn't be opened
at the same time, in the same or in different processes. There would need
to be a shared area per such device (or an area large enough for all
Related to that, the archetype is identified by the device, i.e. /dev/dsp
But there can be several "real" devices, each needing its own archetype.
That leads to having to define minor device numbers for /dev/dsp...
(e.g. based on in/out + device ID, it the ID is determined when /dev/dsp is
opened, and not when it starts playing)
So it gets to be complex, although not that different from ttys.
Is it worth to delay 1.5.11 until those issues are sorted out?
More information about the Cygwin-patches