From owner-freebsd-bluetooth@FreeBSD.ORG Wed Apr 12 19:50:19 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 4C4BB16A405 for ; Wed, 12 Apr 2006 19:50:19 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by mx1.FreeBSD.org (Postfix) with SMTP id A1DE343D6B for ; Wed, 12 Apr 2006 19:50:17 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: (qmail 47649 messnum 6390433 invoked from network[83.70.176.191/unknown]); 12 Apr 2006 19:50:16 -0000 Received: from unknown (HELO rya-online.net) (83.70.176.191) by mail00.svc.cra.dublin.eircom.net (qp 47649) with SMTP; 12 Apr 2006 19:50:16 -0000 Received: (nullmailer pid 4337 invoked by uid 1000); Wed, 12 Apr 2006 19:48:34 -0000 Date: Wed, 12 Apr 2006 20:48:33 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <443D3A30.2020109@savvis.net> References: <20060314181140.GB6870@lbl.pl> <44170EDA.5000406@savvis.net> <1144841743.207833.9946.nullmailer@galant.ukfsn.org> <443D3A30.2020109@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1144871314.024068.10495.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: headset/sco support in freebsd 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: Wed, 12 Apr 2006 19:50:19 -0000 On Wed, 12 Apr 2006, Maksim Yevmenkin wrote: > imo, none of the SOCK_xxx types describes sco exactly. to me its either > SOCK_DGRAM/SOCK_SEQPACKET (more preferred) or SOCK_STREAM (less preferred). [..] > in other words sco "protocol" has (some) SOCK_SEQPACKET properties vs. sco > "protocol" is/can be used to transfer SOCK_STREAM type of data. Thats kind of what I thought too only I was leaning the other way until I saw what the other guys did. Well I am hoping that the sockets part of it will be mostly irrelevant since I am aiming to create a kernel audio device that can be set on top of the SCO code, and in fact after already working on L2CAP (SEQPACKET) and RFCOMM (STREAM) I think SEQPACKET is an easier concept to program, and so would leave the packetising to the audio driver, which may help keep latency down.. regards, iain