From owner-freebsd-multimedia Wed Apr 14 8: 0:21 1999 Delivered-To: freebsd-multimedia@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 732AA14DCD for ; Wed, 14 Apr 1999 08:00:11 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA10239; Wed, 14 Apr 1999 14:37:35 +0200 From: Luigi Rizzo Message-Id: <199904141237.OAA10239@labinfo.iet.unipi.it> Subject: Re: "write denied, another writer is in" To: anton@urc.ac.ru (Anton Voronin) Date: Wed, 14 Apr 1999 14:37:35 +0200 (MET DST) Cc: freebsd-multimedia@FreeBSD.ORG In-Reply-To: <3714A7A7.7A9587C9@urc.ac.ru> from "Anton Voronin" at Apr 14, 99 08:35:01 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1692 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org concurrency control on access to the audio device is largely untested and probably broken (anyways, most device drivers in *BSD/Linux there is no concurrency control at all if this is of any relief). The driver does not have sufficient information, in the most general case of multiple processes writing to it, of which one should be given access to the card. I put the warning msg in the kernel but it just means that you are using the device in the wrong way, not that it can cope with it. This said, the buzz could come because you don;t know which process is writing what to the device -- it might well be that your device is expecting ULAW data all of a sudden it gets a burst of stereo S16 data which are almost sure to cause high volume output -- all of this happens before the device can realize the existence of multiple unsynchronized writers. > P.S. Sometimes cat file.au >/dev/audio gets "stdout: device busy". In this > case all is OK, and there's no any buzz. But more often it succeeds, and the > buzz is produced. > Shouldn't the device be always busy while another process is playing through > it? no -- it all depends on when the second write() hits the driver. BTW the driver does not know how many processes are using it: even if it would block multiple open() (and it does not, because it is pointless) when a process forks you end up with two processes with a valid handle for the device. Worse, when processes call close(), only the last call is propagated to the driver. And if this was not enough, the audio driver (in the voxware model, which i had to replicate) has multiple device entries (i.e. minor numbers) accessing the same hardware. cheers luigi > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message