Date: Tue, 20 Jun 2006 11:31:54 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-multimedia@freebsd.org Subject: Re: Complaints about the sound system with regard to USB Message-ID: <20060620023154.GA8645@cdnetworks.co.kr> In-Reply-To: <200606191346.48853.hselasky@c2i.net> References: <200606191346.48853.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060620023154.GA8645>