Complaints about the sound system with regard to USB

Pyun YongHyeon pyunyh at gmail.com
Tue Jun 20 02:31:49 UTC 2006


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


More information about the freebsd-multimedia mailing list