Message-ID: <455CDE8D.4010009@xmission.com>
Date: Thu, 16 Nov 2006 14:56:29 -0700
From: Brad Midgley <bmidgley@xmission.com>
MIME-Version: 1.0
To: BlueZ development <bluez-devel@lists.sourceforge.net>
References: <455CCAF4.8020007@silicom.fr>
In-Reply-To: <455CCAF4.8020007@silicom.fr>
Subject: Re: [Bluez-devel] SCO on bluez : some architectural tips
Reply-To: BlueZ development <bluez-devel@lists.sourceforge.net>
Content-Type: text/plain; charset="us-ascii"
Sender: bluez-devel-bounces@lists.sourceforge.net
Errors-To: bluez-devel-bounces@lists.sourceforge.net

Fabien

> Due to this, i had to fall back on having the SCO file descriptor 
> available in application process space.

If it's inevitable, I think we could keep the fd in the audio app's 
userspace and mostly pull things off as envisioned. We would have to put 
in some locking to keep applications from trying to open more 
simultaneous sco sockets. I wonder how the other audio servers avoid 
this problem.

Brad


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel