From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <40d186b667ae11ba055234b6316a1a52@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] usb audio From: "Russ Cox" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-dotlfejaosiuhduwzfomzgebuz" Date: Fri, 21 Feb 2003 13:02:29 -0500 Topicbox-Message-UUID: 6d4e492c-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-dotlfejaosiuhduwzfomzgebuz Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit save a kernel stack trace or run ktrace -i. i've been trying to implicate devusb in that panic for many months. if you can reproduce it, please do so! russ --upas-dotlfejaosiuhduwzfomzgebuz Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Fri Feb 21 13:00:29 EST 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Fri Feb 21 13:00:26 EST 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 0B02C19A87; Fri, 21 Feb 2003 13:00:15 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from rapido.vitanuova.com (unknown [62.254.170.97]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id 8142C19A78 for <9fans@cse.psu.edu>; Fri, 21 Feb 2003 12:59:40 -0500 (EST) Message-ID: To: 9fans@cse.psu.edu From: rog@vitanuova.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] usb audio Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Fri, 21 Feb 2003 18:02:16 0000 i just got my new xitel hifi-link (on presotto's recommendation), and hacked madplay so that it sets the speed and number of channels appropriately to the mp3 file. only problem is that doing this when the /dev/audio is already open reliably crashes the kernel. (first i get a write error from usbaudio: writing ep 4 1 w 4 44100 to #U/usb0/1/ctl: permission denied, then the kernel panics with "fault: xxx") i've now fixed it so it closes /dev/audio before writing to audioctl and then reopens it, but it doesn't seem like this should be necessary. the other thing is i'd really like usbaudio to attach to the correct usb port automatically: is there enough information provided by the usb device to automatically identify an audio device (currently i look at the output of usbd -v, or have a look in /dev/usb0)? those issues aside, it works very nicely, thanks... i can finally play mp3 files. (mind you, i've only got two so far!) i guess the next step is a little audio plumbing client that knows how to stop one stream and start another when a new plumbing request comes in; then the world is my jukebox. --upas-dotlfejaosiuhduwzfomzgebuz--