Date: Sat, 24 Aug 2002 06:26:50 -0400 (EDT) From: Dylan Carlson <absinthe@pobox.com> To: FreeBSD-gnats-submit@FreeBSD.org Subject: ports/41966: audio/play: sblive, can cause "Device busy" condition Message-ID: <20020824102650.A7FFB22FD6@laredo.retrovertigo.com>
next in thread | raw e-mail | index | archive | help
>Number: 41966 >Category: ports >Synopsis: audio/play: sblive, can cause "Device busy" condition >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-ports >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Aug 24 03:30:06 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Dylan Carlson >Release: FreeBSD 4.6-STABLE i386 >Organization: >Environment: System: FreeBSD laredo.retrovertigo.com 4.6-STABLE FreeBSD 4.6-STABLE #6: Thu Aug 15 17:29:03 EDT 2002 root@laredo.retrovertigo.com:/usr/obj/usr/src/sys/LAREDO i386 SoundBlaster Live! Value PCI audio device >Description: Multiple processes of play(1) will cause /dev/dsp to busy out. What I mean by this is, if you run an application that uses play(1) for sound events (such as the port net/psi) and that application forks multiple sound events using play, it can cause /dev/dsp to go "busy" and not be released. After such time, no sound application will work until a reboot (or unless you know a magic way to reset /dev/dsp) >How-To-Repeat: The easy way I did this was from within Psi (jabber client). Under the Options screen, you can test the various sound events with the play buttons on that window. Start clicking them fast in succession and you will lock up the dsp. (Or at least in my case it does) >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020824102650.A7FFB22FD6>