[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-multimedia
Subject: Re: Complaints about the sound system with regard to USB
From: Pyun YongHyeon <pyunyh () gmail ! com>
Date: 2006-06-20 2:31:54
Message-ID: 20060620023154.GA8645 () cdnetworks ! co ! kr
[Download RAW message or body]
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
_______________________________________________
freebsd-multimedia@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia
To unsubscribe, send any mail to "freebsd-multimedia-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic