From: Zhu Yanhai <yanhai.zhu@linux.intel.com>
To: liu yang <yangliu.seu@gmail.com>
Cc: linux-bluetooth@vger.kernel.org,
Tan Miaoqing <rabbitrun84@gmail.com>,
Valerio Valerio <vdv100@gmail.com>
Subject: Re: question about 'read' system call of sco socket
Date: Wed, 03 Mar 2010 10:42:54 +0800 [thread overview]
Message-ID: <4B8DCCAE.3030103@linux.intel.com> (raw)
In-Reply-To: <55d43d1d1003020628l543e9af6o535d6fd256c58cb0@mail.gmail.com>
On 03/02/2010 10:28 PM, liu yang wrote:
> Hi experts,
> I have one question about 'read' system call of sco socket. I'm using
> an open source library which implements bluetooth handfree profile on
> linux platform. About our use case, cell phone works as audio gateway
> that all audio received on cell phone will be streamed to linux PC,
> and vice versa. Everything works just fine of audio streaming above
> bluetooth channel. But our special application is very sensitive on
> timing that we need send/receive bluetooth audio frame every 20ms.
> Regarding sending direction, I can tweak MTU of bluetooth donglel
> installed on my linux PC. Let's say, MTU is set to 320 bytes, so every
> 20ms 'send' system call only needs be called one time. ( the audio
> frame conveyed aboved bluetooth is of signed linear 16bit per sample,
> 8K sampling-rate ) But this does not affect receiving direction that
> every 'read' system call on sco socket returns exact 48 bytes. Also I
> find such 'read' event on linux 'poll' is triggered every 10ms. Every
> 10ms, such 'read' action is invoked, but it takes 3 or 4 times
> invokation ( sometimes 3 , sometimes 4) of 'read' to consume this
> 'read' event, which results in 'EAGAIN'. So every 20ms, I get 288
> (48*6) or 336 (48*7) bytes, not exact 320 I expect.
>
> Shortly, my question is how to receive ( 'read' system call ) exact
> 320 bytes every 20ms.
>
> Thanks
>
> Kandy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi Yang,
I'm not a expert at this. IIRC SCO connection is designed to carry fixed
rated data, which is 64kbps[1]. In your case, you are expecting about
16bit*8K = 128kbps, which is beyond of SCO's capability. Maybe you can
consider creating two SCO links (the upper limit is 3 between two
Bluetooth devices) to carry your data or maybe you could consider using
a eSCO link?
Again, I'm not good at this, just saying...
Regards,
Zhu Yanhai
[1] Bluetooth specification Version 2.1, Vol 1, Page 44,
3.5.5 Synchronous connection-oriented (SCO)
prev parent reply other threads:[~2010-03-03 2:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 14:28 question about 'read' system call of sco socket liu yang
2010-03-03 2:42 ` Zhu Yanhai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B8DCCAE.3030103@linux.intel.com \
--to=yanhai.zhu@linux.intel.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=rabbitrun84@gmail.com \
--cc=vdv100@gmail.com \
--cc=yangliu.seu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).