From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 18 17:22:57 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F33FB16A400 for ; Tue, 18 Apr 2006 17:22:56 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64C3043D45 for ; Tue, 18 Apr 2006 17:22:56 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id B1D5A3BE6C; Tue, 18 Apr 2006 12:22:54 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23224-02-30; Tue, 18 Apr 2006 12:22:54 -0500 (CDT) Received: from [10.254.186.111] (sntc04ep01.savvis.net [64.14.1.106]) by mailgate1b.savvis.net (Postfix) with ESMTP id 437FA3BE22; Tue, 18 Apr 2006 12:22:54 -0500 (CDT) Message-ID: <4445206D.4030109@savvis.net> Date: Tue, 18 Apr 2006 10:22:53 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iain Hibbert References: <4423D096.2010205@udc.es> <44248823.3040907@savvis.net> <1145275616.851775.858.nullmailer@galant.ukfsn.org> In-Reply-To: <1145275616.851775.858.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: USB isoc xfers X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2006 17:22:57 -0000 Iain, > I am having a little trouble with the USB isoc data, and I see > you also had the same trouble.. ok > | 3) Understand and fix isoc. USB transfers (SCO data) > | > | Currenty device reports that is got zero bytes and calls > | isoc_in_complete callback over and over again. Why? > | Also might need to setup at least two isoc. transfers in > | both directions and switch them on the fly. Just to ensure > | there at least one transfer at any time ready to run. > > if you solved this already, any tips? well, i'd like to think so :) please take a look at http://mumu.org/~myevmenk/bluetooth/ng_ubt.c http://mumu.org/~myevmenk/bluetooth/ng_ubt_var.h this is a work in progress code that i used to receive sco data from the headset. this is NOT complete, its for the reference purposes. i have not tried to send sco data. > So far I am supposing that for USB isoc transfers, the transfer would be > fulfilled in any case after a timeout (3ms ?) which is why I get zero > bytes, and I would be happy with that but it seems that the uhci/usbdi > part gets lost in a loop when I restart the xfer (possibly caused by some > DIAGNOSTIC logic) the way i understand it, isoc transfers have reserved bandwidth. it does not matter if there are data or not, the bandwidth is reserved anyway. the trick is (imo) to have enough pending isoc transfers to make sure time constrains are met. > To have isoc xfers consuming processor cycles continuously when no data is > being sent does not seem like a great idea though, maybe I got the wrong > impression there.. i do not think we do have a choice here. since the bandwidth is reserved, there has to be a transfer pending, otherwise time constrains are not met. thanks, max