Subject: Re: audio open()/close() inconsistency
To: Aymeric Vincent <>
From: Quentin Garnier <>
List: tech-kern
Date: 09/16/2007 15:42:54
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 16, 2007 at 03:03:00PM +0200, Aymeric Vincent wrote:
>        hi,
> sorry for the lack of a better subject.
> Basically, audio_open() allows a program to open an audio device in
> read-mode and another program to open it in write-mode (in whatever
> order).
> However, when any of the programs calls audio_close(), the device is
> close()d for everybody.
> Either this is an overlook in audio_close(), because the rest of the
> audio framework seems that it can handle the situation. Or, we should
> make sure no two programs can access the same audio driver at the same
> time.
> In my local source tree, I have the following patch which goes for the
> second solution, because I've seen audio drivers stop any activity
> when their close() function is called, amplifying the behaviour of
> audio_close() anyway.
> Anyone who has an opinion on this issue and/or the guts to modify
> audio_close(), the ill-behaved drivers, and check that it doesn't have
> wrong implications?
> BTW, as it stands now, it is easy to stop audio from working: just
> play some music, and at the same time use audiorecord. As soon as
> audiorecord finishes, the audio output will be stuck.

While I don't deny there might be a bug, your analysis is incorrect:
the close() function from the cdevsw structure is called only once, when
there is no remaining file descriptor using the device.

Quentin Garnier - -
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.6 (NetBSD)