Wolfgang Solfrank wrote:

> Hi,
>
> > > >The audio chip reports in dmesg that it is full duplex so i guess the
> > > >driver is to blame ?
> > >
> > > I have a feeling that this is actually a consequence of the way the MI audio
> > > driver works.  Look at audio_open() in sys/dev/audio.c.
> >
> > And the way device close works in NetBSD (and othet BSDs) I don't see
> > how you can implement it any other way.  :(
>
> Hmm, one could argue that it's not the driver's (or any other part's of the
> kernel) business to prevent multiple opens of a device...

Yes, but having multiple opens for write (or read) of an audio device will
lead to bad things (i.e. garbled sound) in 99.9% of the cases.
I think it makes sense to disallow that.  Just like multiple opens of a tape
has traditionally be disallowed.

If the driver is rewritten to mix all the incoming data, then we have a
different situation.  But I'll let someone else figure out how doable that is.
The way I can see of doing this is again prevented by the close semantics
in traditional unix kernels (i.e. you would like to allocate some data structures
on open and free them on close, but the driver only gets called on the last close.
You also need to know how many opens you currently have to compute the
attentuation level.)

--

        -- Lennart