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.

Thanks for any opinion,
 Aymeric

Index: audio.c
===================================================================
RCS file: /cvsroot/src/sys/dev/audio.c,v
retrieving revision 1.223
diff -u -u -r1.223 audio.c
--- audio.c	14 Aug 2007 21:34:03 -0000	1.223
+++ audio.c	16 Sep 2007 13:00:16 -0000
@@ -1344,8 +1344,12 @@
 	DPRINTF(("audio_open: flags=0x%x sc=%p hdl=%p\n",
 		 flags, sc, sc->hw_hdl));
 
+#if 0
 	if (((flags & FREAD) && (sc->sc_open & AUOPEN_READ)) ||
 	    ((flags & FWRITE) && (sc->sc_open & AUOPEN_WRITE)))
+#else
+	if (sc->sc_open != 0)
+#endif
 		return EBUSY;
 
 	if (hw->open != NULL) {