From owner-freebsd-multimedia@FreeBSD.ORG Tue Jun 20 02:31:49 2006 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ACB216A47A for ; Tue, 20 Jun 2006 02:31:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9958343D46 for ; Tue, 20 Jun 2006 02:31:48 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so716354nzf for ; Mon, 19 Jun 2006 19:31:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=JNlT8i+NzWMyj7Wz+7hKqGDDcet2E8MhwufLn0u1usaDARMSro+uexwX+5o5hCVSNDvfYhtmls+C6exvDm3jwHdiIzbYmZ1BnS1pb93/EpTgWd/IrT6tPUedYLcLNZAy/Dc/yxjPipnUR4oSFSr9j852CwA2/csY6newHpSzGio= Received: by 10.37.22.76 with SMTP id z76mr2085829nzi; Mon, 19 Jun 2006 19:31:48 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 15sm10572913nzn.2006.06.19.19.31.45; Mon, 19 Jun 2006 19:31:47 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k5K2Vu3l009287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 11:31:56 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k5K2VsdY009286; Tue, 20 Jun 2006 11:31:54 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 20 Jun 2006 11:31:54 +0900 From: Pyun YongHyeon To: Hans Petter Selasky Message-ID: <20060620023154.GA8645@cdnetworks.co.kr> References: <200606191346.48853.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606191346.48853.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-multimedia@freebsd.org Subject: Re: Complaints about the sound system with regard to USB X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 02:31:49 -0000 On Mon, Jun 19, 2006 at 01:46:48PM +0200, Hans Petter Selasky wrote: > Hi, > > I have some complaints about the sound system with regard to USB. > > 1) If you are playing sound, and unplug the sound device, the system is going > to come down with a panic, hence "pcm_unregister()" returns EBUSY, and that > is not allowed when a USB device is detached. > I have zero experience on USB sound hardware. So I can't say anything on USB issues. :-( > 2) The locking system is not right. Why must the sound device driver unlock > its private lock before calling "chn_intr()" ? I see why, because else you > get a dead lock: > > if (ch->run) { > ICH_UNLOCK(sc); > chn_intr(ch->channel); > ICH_LOCK(sc); > } > > Solution: > > 1) It is not impossible to kill opened devices at detach. > > 2) Please use only one lock per "sound-controller". All "child" structures > should be protected by this lock, PCM, MIDI, whatever. And when you call up, > lock this lock before doing the call, ala CHN_LOCK(). And when you call down, > this lock should already be locked. > > /*---------------------------------------------------------------------------* > * pcm_controller_allocate > * > * NOTE: all sub-controllers are under the same lock! > *---------------------------------------------------------------------------*/ > struct pcm_controller * > pcm_controller_allocate(u_int8_t portable, u_int8_t sub_controllers) > > Any comments? > Wouldn't this add an additional overhead? I think the correct solution is to remove the limitation that chn_intr couldn't be called with a driver lock held. I think sound subsystem should provide a mechanism not a policy. Choosing which type of lock to use and how many locks are needed is completely up to driver writers. As sound hardware is very slow device it needs a special locking strategy, I think. For instance you may not want to serialize accessing a sound hardware if hardware in question has multiple independent playback/record/MIDI capability. Also some advanced hardwares have a kind of IOMMU to support large sound font. Accessing a mixer or joy stick may influence its playback/recording quality as it requires accessing hardware/codec registers which in turn needs to access the IOMMU. -- Regards, Pyun YongHyeon