[Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Fabien Chevalier]

SGkgYWxsLAoKSSByZWNlbnRseSBwdXJjaGFzZWQgYSBuZXcgY29tYm8gQTJEUC9IRlAgaGVhZHNl
dCBmcm9tIFNvbnkgRXJpY3Nzb24uClRoaXMgd2FzIHRoZSBmaXJzdCB0aW1lIGkgd2FzIGFibGUg
dG8gdHJ5IEZyZWRlcmljJ3MgYTJkcGQgZGFlbW9uLiA6LSkKSSB3b3JrZWQgZmluZSAoZXhjZXB0
IHdpdGggc29tZSBhdWRpbyBjdXRzIG9yIGV4Y2Vzc2l2ZSBkZWxheXMgLSBtb3JlIG9uIAp0aGF0
IGxhdGVyKS4KVGhlbiBpIGRlY2lkZWQgdG8gdXBkYXRlIG15IG9sZCAyLjYuMjAga2VybmVsIHRv
IGEgcmVjZW50IDIuNi4yMiBrZXJuZWwsIAppbmNsdWRpbmcgdGhlIG5vdyBkZWJpYW4gZGVmYXVs
dCBzZXR0aW5ncyA6IGR5bmFtaWMgdGlja3MgYW4gaGlnaCAKcmVzb2x1dGlvbiB0aW1lcnMuCgpU
aGVuIGkgc3RhcnRlZCB0byBleGhpYml0IHRoZSBiZWhhdmlvdXIgb3RoZXIgcGVvcGxlIGhhdmUg
YmVlbiAKcmVwb3J0aW5nLCB3aGljaCBtZWFucyBzcHVyaW91cyBkaXNjb25uZWN0cyAoaSBkaWRu
J3QgYWN0aXZhdGUgdGhlIHJldHJ5IApwYXRjaCkuCkkgc3RhcnRlZCBkZWJ1Z2dpbmcgdGhlIGtl
cm5lbCBwYXJ0IHRvIHNlZSB3aGVyZSB0aGUgRUFHQUlOIGludCB0aGUgCkwyQ0FQIHNvY2tldCB3
cml0ZSBjYWxsIHdhcyBjb21taW5nIGZyb20uIExvb2tzIGxpa2UgaXQgd2FzIGNvbWluZyBmcm9t
IAp0aGUgc29ja19hbGxvY19zZW5kX3Bza2IgZnVuY3Rpb24sIHdoaWNoIGlzIHJlc3BvbnNpYmxl
IHRvIGFsbG9jYXRlIApzb2NrZXQgYnVmZmVycywgcHJlY2lzZWx5IGF0IGxpbmUgIDExOTEgb2Yg
IG5ldC9jb3JlL3NvY2suYy4gVGhpcyBsaW5lIAp0ZXN0cyB0byBzZWUgaWYgdGhlIHNvY2tldCBx
dWV1ZSBpcyBmdWxsLiBJZiBpdCBmYWlscyBpdCByZXR1cm5zIEVBR0FJTi4KSW4gb3VyIGNhc2Ug
dGhhdCBtZWFudCB0aGF0IHRoZSB1c2VyIHNwYWNlIGRhZW1vbiB3YXMgc2VuZGluZyBkYXRhIHdh
eSAKdG9vIGZhc3QgKGkgYWxzbyBub3RpY2VkIHRoYXQgeG1tcyB0aW1lIGRpc3BsYXkgd2FzIHJ1
bm5pbmcgd2F5IHRvbyBmYXN0IAphbHNvKS4KCkFmdGVyIGEgd2hpbGUgaSB3YXMgYWJsZSB0byBk
aXNjb3ZlciB3aGVyZSB0aGUgc2xlZXAgYW5kIHdhaXQgam9iIHdhcyAKcGVyZm9ybWVkIGZvciBh
MmRwIHN0cmVhbWluZy4gVGhhdCB3YXNuJ3QgcmVhbGx5IGVhc3kgdG8gZmluZCBhcyB0aGVyZSAK
YXJlIG1hbnkgcGxhY2VzIGluIHRoZSBjb2RlIHRoYXQgc2VlbSB0byBiZSB0cnlpbmcgdG8gaGFu
ZGxlIHRoaXMgdGFzaywgCmJ1dCBtb3N0IG9mIHRoZW0gaGF2ZSB0aGUgc2xlZXAgY2FsbCBjb21t
ZW50ZWQgOi0oCgpMb29rcyBsaWtlIHRoZSBqb2IgaXMgcGVyZm9ybWVkIGluIHRoZSBhMmRwZC5j
IGZpbGUsIGxpbmUgMTU5NDoKICAgICAgICBpZihwb2xsaW5mb3MucG9sbHRpbWVvdXQ+MCkKICAg
ICAgICAgICAgICAgIHVzbGVlcChwb2xsaW5mb3MucG9sbHRpbWVvdXQpOwoKCkkgYWRkZWQgc29t
ZSB0cmFjZXMgdG8gdGhpcyBjb2RlIHRvIHNlZSBob3cgbXVjaCB3ZSB3aGVyZSB0cnlpbmcgdG8g
CnNsZWVwLiBUbyBteSBzdXByaXNlIHRoZSB0cmFjZSBzaG93ZWQgdGhhdCB3ZSB3aGVyZSBtb3N0
IG9mIHRoZSB0aW1lIApzbGVlcGluZyBmb3IgYXMgbGl0dGxlIGFzIDUwIHVzZWMsIHdoaWNoIGRv
ZXNuJ3QgbWFrZXMgc2Vuc2UuLi4sIGJlY2F1c2UgCnNsZWVwaW5nIHByZWNpc2lvbiBpcyBib3Vu
ZCB0byB0aGUgdGltZXIgaW50ZXJydXB0IGZyZXF1ZW5jeSwgd2hpY2ggaXMgCnVzdXN1YWxseSBz
ZXQgYmV0d2VlbiAxMDBIWiBhbmQgMTAwMEhaICghKQpUaGlzIG9mIGNvdXJzZSB1bmxlc3MgeW91
IHVzZSBhIGtlcm5lbCB3aXRoIGhpZ2ggcmVzb2x1dGlvbnMgdGltZXJzIAplbmFibGVkLCBpbiB0
aGF0IGNhc2UgeW91IHJlYWxseSBnZXQgd2hhdCB5b3UgYXNrIGZvciBpZiB5b3VyIGhhcmR3YXJl
IApzdXBwb3J0cyBpdCwgd2hpY2ggbG9va3MgdG8gYmUgdGhlIGNhc2Ugb24gbm93YWRheXMgY29t
cHV0ZXJzLCBpbmNsdWRpbmcgCm15IGxhcHRvcC4gOi0pCgpUbyBtYWtlIHNvbWUgbW9yZSBmdW4g
YWJvdXQgdGhlIGlzc3VlLCBpIHNpbXBseSByZXBsYWNlZCB0aGUgY2FsbCB3aXRoIGEgCnVzbGVl
cCgxMDAwMCksIHdoaWNoIHdvdWxkIGJlIHdoYXQgeW91IHdvdWxkIGdldCBhbnl3YXkgd2l0aCB0
aGUgbm9uIEhSIAp0aW1lciBrZXJuZWwuLi4gImV0IHZvaWzDoCIgOiBpdCBzdGFydGVkIHRvIHdv
cmsgYXMgYmVmb3JlLgoKQXMgYSBjb25jbHVzaW9uIChTb3JyeSB0byBoYXZlIHRvIHNheSB0aGF0
IEZyZWRlcmljIDstKSApLCBidXQgaXQgbG9va3MgCnRoYXQgdGhlIHdheSBhMmRwZCBoYW5kbGVz
IHRpbWUgaXMgY3VycmVudGx5IGJhZGx5IGJyb2tlbiA6LSgKClJlZ2FyZHMsCgpGYWJpZW4KCgot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tClRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogU3BsdW5r
IEluYy4KU3RpbGwgZ3JlcHBpbmcgdGhyb3VnaCBsb2cgZmlsZXMgdG8gZmluZCBwcm9ibGVtcz8g
IFN0b3AuCk5vdyBTZWFyY2ggbG9nIGV2ZW50cyBhbmQgY29uZmlndXJhdGlvbiBmaWxlcyB1c2lu
ZyBBSkFYIGFuZCBhIGJyb3dzZXIuCkRvd25sb2FkIHlvdXIgRlJFRSBjb3B5IG9mIFNwbHVuayBu
b3cgPj4gIGh0dHA6Ly9nZXQuc3BsdW5rLmNvbS8KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KQmx1ZXotZGV2ZWwgbWFpbGluZyBsaXN0CkJsdWV6LWRldmVs
QGxpc3RzLnNvdXJjZWZvcmdlLm5ldApodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0
cy9saXN0aW5mby9ibHVlei1kZXZlbAo=

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Marcel Holtmann]

Hi Fabien,

> I recently purchased a new combo A2DP/HFP headset from Sony Ericsson.
> This was the first time i was able to try Frederic's a2dpd daemon. :-)

you might wanna focus on the Bluetooth audio service in bluez-utils (the
code got committed today) which now has A2DP support.

Parts are based on the work from bluetooth-alsa, but the overall design
concept is a little bit different. For example is the SBC encoding done
inside the ALSA plugin and not inside the daemon. This allows us to
avoid any unnecessary copying of data between processes. My laptop
showed xmms running at 5% CPU and that includes MP3 decoding and then
SBC encoding.

I have seen some weird behavior with this when the playback speed is way
to fast. This might be related or totally unrelated. I simply don't
know.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Fabien Chevalier]

Hi Marcel,

> Hi Fabien,
> 
>> I recently purchased a new combo A2DP/HFP headset from Sony Ericsson.
>> This was the first time i was able to try Frederic's a2dpd daemon. :-)
> 
> you might wanna focus on the Bluetooth audio service in bluez-utils (the
> code got committed today) which now has A2DP support.

Ho good, i'm gonna start having a look at it then !

> 
> Parts are based on the work from bluetooth-alsa, but the overall design
> concept is a little bit different. For example is the SBC encoding done
> inside the ALSA plugin and not inside the daemon. 

That's *great* news !! That always shocked me to have the sound data go 
through the sound daemon :-)

This allows us to
> avoid any unnecessary copying of data between processes. My laptop
> showed xmms running at 5% CPU and that includes MP3 decoding and then
> SBC encoding.

Agreed. + reduced latency :-)
> 
> I have seen some weird behavior with this when the playback speed is way
> to fast. This might be related or totally unrelated. I simply don't
> know.

I'm gonna start to play with it then.

I was planning to start some a2dp related work myself on it... if only 
it wasn't already done. :-)

Could you tell me who's working on the audio service ?
How should i submit patches / possible functionnal improvements to it 
(are the people working on it on the list)?

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Frederic Dalleau]

> you might wanna focus on the Bluetooth audio service in bluez-utils (the
> code got committed today) which now has A2DP support.

That's great news !!! I was thinking of this coming out soon, but didn't expect something so early.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Marcel Holtmann]

Hi Frederic,

> > you might wanna focus on the Bluetooth audio service in bluez-utils (the
> > code got committed today) which now has A2DP support.
> 
> That's great news !!! I was thinking of this coming out soon, but didn't expect something so early.

the CSR based headphones seem to work pretty good so far. We have some
minor issues on the AVDTP protocol level, but they are fixable. The
current big issue are the Broadcom based headphones. While CSR seems to
be quite forgiving if you send data too fast (actually I think they use
flow control in the baseband to slow us down), the Broadcom ones are
not. We have to send the next SBC frame at the exact time slot.
Otherwise the audio sounds too fast or frames are skipped. If you have
any ideas on how we can improve pcm_bluetooth.c (yes, that handling is
inside the ALSA plugin), I would like to know.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Fabien Chevalier]

Hi Marcel & Frederic,

> Hi Frederic,
> 
>>> you might wanna focus on the Bluetooth audio service in bluez-utils (the
>>> code got committed today) which now has A2DP support.
>> That's great news !!! I was thinking of this coming out soon, but didn't expect something so early.
> 
> the CSR based headphones seem to work pretty good so far. We have some
> minor issues on the AVDTP protocol level, but they are fixable. The
> current big issue are the Broadcom based headphones. While CSR seems to
> be quite forgiving if you send data too fast (actually I think they use
> flow control in the baseband to slow us down), the Broadcom ones are
> not. We have to send the next SBC frame at the exact time slot.
> Otherwise the audio sounds too fast or frames are skipped. If you have
> any ideas on how we can improve pcm_bluetooth.c (yes, that handling is
> inside the ALSA plugin), I would like to know.

The issue you plotted here is a well known issue. Basically a2dp/avdtp 
profile does not specify how flow control is supposed to be handled, 
which leaves it open to implementation-specific behaviours (play faster, 
drop samples, use l2cap flow control...). :-(
The way handset makers have solved the issue is to throttle the data 
sending, to avoid triggering moonlight specific headset behaviours.
What i would suggest is to do the same thing using usleep() calls inside 
the alsa plugin.

That will trigger another issue which is clock drifting, because the 
headset will supposedly consume data at master clock speed, while we 
will send data at host clock speed. I think for this one the best is to 
calculate and compensate for the drift using OCF_READ_CLOCK_OFFSET hci 
command: however it's just my wild guess ... ;-)

I hope that helps...

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Marcel Holtmann]

Hi Fabien,

> >>> you might wanna focus on the Bluetooth audio service in bluez-utils (the
> >>> code got committed today) which now has A2DP support.
> >> That's great news !!! I was thinking of this coming out soon, but didn't expect something so early.
> > 
> > the CSR based headphones seem to work pretty good so far. We have some
> > minor issues on the AVDTP protocol level, but they are fixable. The
> > current big issue are the Broadcom based headphones. While CSR seems to
> > be quite forgiving if you send data too fast (actually I think they use
> > flow control in the baseband to slow us down), the Broadcom ones are
> > not. We have to send the next SBC frame at the exact time slot.
> > Otherwise the audio sounds too fast or frames are skipped. If you have
> > any ideas on how we can improve pcm_bluetooth.c (yes, that handling is
> > inside the ALSA plugin), I would like to know.
> 
> The issue you plotted here is a well known issue. Basically a2dp/avdtp 
> profile does not specify how flow control is supposed to be handled, 
> which leaves it open to implementation-specific behaviours (play faster, 
> drop samples, use l2cap flow control...). :-(
> The way handset makers have solved the issue is to throttle the data 
> sending, to avoid triggering moonlight specific headset behaviours.
> What i would suggest is to do the same thing using usleep() calls inside 
> the alsa plugin.

we have to calculate the actual time of an SBC frame and then transmit
it and then sleep the rest of the time before sending the next frame.
However to have at least a little bit buffer, we should encode something
around 3 L2CAP packets ahead. Should be something like 9-12 SBC frames.

> That will trigger another issue which is clock drifting, because the 
> headset will supposedly consume data at master clock speed, while we 
> will send data at host clock speed. I think for this one the best is to 
> calculate and compensate for the drift using OCF_READ_CLOCK_OFFSET hci 
> command: however it's just my wild guess ... ;-)

I can't see how the clock offset will help us here. It is only important
for paging devices. All the other time, the device will re-sync their
clocks as needed.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Frederic Dalleau]

Marcel, Fabien,

> > > We have to send the next SBC frame at the exact time slot.
> > > Otherwise the audio sounds too fast or frames are skipped. If you have
> > > any ideas on how we can improve pcm_bluetooth.c (yes, that handling is
> > > inside the ALSA plugin), I would like to know.
> > 
> > The way handset makers have solved the issue is to throttle the data 
> > sending, to avoid triggering moonlight specific headset behaviours.
> > What i would suggest is to do the same thing using usleep() calls inside 
> > the alsa plugin.
> 
> we have to calculate the actual time of an SBC frame and then transmit
> it and then sleep the rest of the time before sending the next frame.
> However to have at least a little bit buffer, we should encode something
> around 3 L2CAP packets ahead. Should be something like 9-12 SBC frames.

One sbc frame is very short (350 sbc frames / s). This will only be
possible if you have high resolution timers ;)

a2dpd used to accumulate as much sbc frames as possible in one L2CAP
packet based on mtu. This of course caused latency, but it allowed to
wait using a low resolution timer.

90% latency in a2dpd was due to the "mixer" implementation.

I'm thinking about having sbc encoding inside the plugin. I'm not
convinced, mostly for these reasons :

Even if enough data is buffered, you are not guaranteed that the
application will send data in time. Worse, if enough data is buffered,
the application can choose not to send more data. The application calls
snd_pcm_get_delay(), then sleeps for the remaining delay, then sends new
data. This is typically true at the end of a stream. The application
write what can be written, then wait until the stream underrun, without
writing anymore.

Using usleep in the alsaplugin has been an issue for some player
specially when video and sound must be decoded. Decoding video takes a
lot of time, and sleeping inside the loop is simply not possible.

> I can't see how the clock offset will help us here. It is only important
> for paging devices. All the other time, the device will re-sync their
> clocks as needed.

AFAIK clock drifting has not been an issue to me before. 

Frederic


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Luiz Augusto von Dentz]

Hi,

I took some time investigating this issue, it really seems to
be a out of sync problem. As marcel said we send data too
fast and in some headset this cause the stream playback
to sound a lot faster than it should. As I dont have one of
those headset with this problem I emulate mine using a
computer + a2recv, and for my surprise any of the dongle
 I tried to plugged had the same issue, so it seems it is not
direct connected to broadcom chips, but it probably tied
 with the way the sink is implemented.

The problem occurs because a2recv has no buffer after
decode the packet, it simple sent to dsp in the frequency
it receives from bluetooth, and this dont seem to be the way
we expected a sink to work. I also run tests inserting a
usleep(10000) after sending a packet, this helped a lot in the
way I got almost perfect audio in the emulated sink. But still
there it sounds noisy if I plug a good wire headset on sink,
this is probably because the frames are not all in the same
rate, we dont send frame per frame so the sleep only helps to
synchronize some frames  between the packets but not the
ones that are within the packet.

Im not sure if this can be solved with a flow control on L2CAP,
and Im also not sure if the headset that do work use it, well
I guess they couldn't because we dont support that too, right?
This leads me to believe headsets should have its own decoded
buffer that should be consumed in the proper audio rate not
the stream rate as a2recv seems to assume.

We can of course send frame per frame in the exact frame rate
we want the audio to be played, but we should considerer this
problems when acting as a sink.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Fabien Chevalier]

Hi all,

Please find some comments.

> Marcel, Fabien,
> 
>>>> We have to send the next SBC frame at the exact time slot.
>>>> Otherwise the audio sounds too fast or frames are skipped. If you have
>>>> any ideas on how we can improve pcm_bluetooth.c (yes, that handling is
>>>> inside the ALSA plugin), I would like to know.
>>> The way handset makers have solved the issue is to throttle the data 
>>> sending, to avoid triggering moonlight specific headset behaviours.
>>> What i would suggest is to do the same thing using usleep() calls inside 
>>> the alsa plugin.
>> we have to calculate the actual time of an SBC frame and then transmit
>> it and then sleep the rest of the time before sending the next frame.
>> However to have at least a little bit buffer, we should encode something
>> around 3 L2CAP packets ahead. Should be something like 9-12 SBC frames.
> 
> One sbc frame is very short (350 sbc frames / s). This will only be
> possible if you have high resolution timers ;)
> 
> a2dpd used to accumulate as much sbc frames as possible in one L2CAP
> packet based on mtu. This of course caused latency, but it allowed to
> wait using a low resolution timer.
> 
> 90% latency in a2dpd was due to the "mixer" implementation.
> 
> I'm thinking about having sbc encoding inside the plugin. I'm not
> convinced, mostly for these reasons :
> 
> Even if enough data is buffered, you are not guaranteed that the
> application will send data in time. Worse, if enough data is buffered,
> the application can choose not to send more data. The application calls
> snd_pcm_get_delay(), then sleeps for the remaining delay, then sends new
> data. This is typically true at the end of a stream. The application
> write what can be written, then wait until the stream underrun, without
> writing anymore.

I'm not sure i understood your last paragraph : could you please 
expand/reformulate ?

> 
> Using usleep in the alsaplugin has been an issue for some player
> specially when video and sound must be decoded. Decoding video takes a
> lot of time, and sleeping inside the loop is simply not possible.

Ok, then we have to implement snd_pcm_get_delay() and offer the option 
to the application to sleep itself (or do other time consuming tasks 
such as video decoding). However when the application sends data too 
fast (such as a simple aplay) we *have* to do the sleeping ourselves to 
prevents cuts on the headset side :-)
This means we have to implement some kind of "virtual buffer" and sleep 
only after this buffer is full, and not after each packet is sent.
Or at first we can just say "go to hell" to those applications that do 
everything in the same thread and choose to solve the issue later :-)

However i don't see how it is related to the fact encoding is done (or 
not done) in the plugin itself...)

> AFAIK clock drifting has not been an issue to me before. 

Well, it is a physical fact. People at my company have been spending 
weeks, if not months implementing all those 
streaming/clocking/throttling things for their a2dp implementation, so 
that it would work with most of the a2dp headsets on the market today 
:-(. An the issues we've seen here they've already solved :-)
The fact you haven't encountered it before can be explained by the fact 
that:
  * you haven't been paying attention to it :250 ppm is ~ 15 
milliseconds per minute: if you're licky enough you just haven't 
discovered yet. ;-)
  * you used headsets that compensate for clock drifting by dynamically 
adjusting their playing speed to the rate at which data arrive. However 
not all do. My brand new Sony Ericsson just drops the sample or inserts 
audio cuts for instance :-(

In fact in a previous mail i said i got perfect sound quality with the 
bluetooth audio service (which means no audio cuts whatsoever), while 
only good sound quality with a2dpd : i from time to time get some cuts. 
:-( It may or may not be related to those issues : i don't know.

Cheers,

Fabien



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Frederic Dalleau]

Hi,

I'll try to be more clear,

> > Even if enough data is buffered, you are not guaranteed that the
> > application will send data in time. Worse, if enough data is buffered,
> > the application can choose not to send more data. The application calls
> > snd_pcm_get_delay(), then sleeps for the remaining delay, then sends new
> > data. This is typically true at the end of a stream. The application
> > write what can be written, then wait until the stream underrun, without
> > writing anymore.
> 
> I'm not sure i understood your last paragraph : could you please 
> expand/reformulate ?

Let's take an example : An application write 40 ms of music.
If you internally buffer the data, then the application will consider it
 written (not played yet).
The application will then wait for the data to be played by repeatedly 
asking the delay until is it 0. However, that application 
will NOT call write(), preventing the plugin code to be executed.

I already hear you saying, let's put the code in getdelay() too. This is not possible
because the application can also call getdelay() once and wait, or even not call
getdelay() at all, because the number of music data is known...

However, using a thread can solve this issue.

> Ok, then we have to implement snd_pcm_get_delay() and offer the option 
> to the application to sleep itself (or do other time consuming tasks 
> such as video decoding). However when the application sends data too 
> fast (such as a simple aplay) we *have* to do the sleeping ourselves to 
> prevents cuts on the headset side :-)

Aplay is not sending the data too fast. aplay tries to fill the sound
card buffer as 100% of sound playing application do.
Buffer size being known, delay determine available space. When there is
space, aplay writes data and that's all.

The current plugin delay implementation is the number of data written
(not played) => delay is always 0 => buffer is always empty => aplay
fills it => plugin have to wait in the write() call.

> This means we have to implement some kind of "virtual buffer" and sleep 
> only after this buffer is full, and not after each packet is sent.

I'm not sure we can assume an headset will buffer the received packets.
data should be sent as regularly as possible.

> Or at first we can just say "go to hell" to those applications that do 
> everything in the same thread and choose to solve the issue later :-)

In fact, the only application to care about is the sound server.

Frederic



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Marcel Holtmann]

Hi Frederic,

> > > Even if enough data is buffered, you are not guaranteed that the
> > > application will send data in time. Worse, if enough data is buffered,
> > > the application can choose not to send more data. The application calls
> > > snd_pcm_get_delay(), then sleeps for the remaining delay, then sends new
> > > data. This is typically true at the end of a stream. The application
> > > write what can be written, then wait until the stream underrun, without
> > > writing anymore.
> > 
> > I'm not sure i understood your last paragraph : could you please 
> > expand/reformulate ?
> 
> Let's take an example : An application write 40 ms of music.
> If you internally buffer the data, then the application will consider it
>  written (not played yet).
> The application will then wait for the data to be played by repeatedly 
> asking the delay until is it 0. However, that application 
> will NOT call write(), preventing the plugin code to be executed.
> 
> I already hear you saying, let's put the code in getdelay() too. This is not possible
> because the application can also call getdelay() once and wait, or even not call
> getdelay() at all, because the number of music data is known...
> 
> However, using a thread can solve this issue.

while I am against threads, for the plugin it is actually okay since
ALSA uses threads anyway. For the audio service, threads are not welcome
and hereby forbidden by me ;)

> > Or at first we can just say "go to hell" to those applications that do 
> > everything in the same thread and choose to solve the issue later :-)
> 
> In fact, the only application to care about is the sound server.

Actually the audio service is not doing any audio handling at all. It
only drivers AVDTP signaling and parameter negotiation. That's it. The
plugin is responsible for the whole media channel. This actually
includes the AVDTP header for that channel including the SBC header and
the actual SBC encoded data.

The audio service gives the plugin a file descriptor to use and then the
plugin takes care of everything until the audio service decides to
disconnect or the remote side terminates the connection. This includes
start, stop etc., but that are implementation details.

The I expect the following applications to work: aplay, xmms/beep,
totem, ekiga and skype.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Fabien Chevalier]

Hi all, please find some comments below.

> Let's take an example : An application write 40 ms of music.
> If you internally buffer the data, then the application will consider it
>  written (not played yet).
> The application will then wait for the data to be played by repeatedly 
> asking the delay until is it 0. However, that application 
> will NOT call write(), preventing the plugin code to be executed.
> 
> I already hear you saying, let's put the code in getdelay() too. This is not possible
> because the application can also call getdelay() once and wait, or even not call
> getdelay() at all, because the number of music data is known...
> 
> However, using a thread can solve this issue.
> 
>> Ok, then we have to implement snd_pcm_get_delay() and offer the option 
>> to the application to sleep itself (or do other time consuming tasks 
>> such as video decoding). However when the application sends data too 
>> fast (such as a simple aplay) we *have* to do the sleeping ourselves to 
>> prevents cuts on the headset side :-)
> 
> Aplay is not sending the data too fast. aplay tries to fill the sound
> card buffer as 100% of sound playing application do.
> Buffer size being known, delay determine available space. When there is
> space, aplay writes data and that's all.
> 
> The current plugin delay implementation is the number of data written
> (not played) => delay is always 0 => buffer is always empty => aplay
> fills it => plugin have to wait in the write() call.
> 

Ok, this time i understood. I agree with you. Which means two things:
  * i basically screwed up the pcm plugin i did a while ago for headsetd 
:-(. I was wrongs about the sleeping stuff. I understood alsa dynamic 
behaviour the wrong way.
  * ALSA API has the builtin assomption that the data gets transmitted 
using a hardware ring buffer, which is not the bluetooth way of things 
when you send packets one after the other.

This means we have to workaround this by implementing a virtual buffer 
with a virtual hardware pointer.
While as Marcel, i'm not a big fan of threads, i'd tend to see them here 
as the less worse alternative we have :-) : so i'd say : let's go with 
threads !!

> I'm not sure we can assume an headset will buffer the received packets.

Well it does. However how much is left completely unspecified by the 
bluetooth specs. :-(

> In fact, the only application to care about is the sound server.

Could you be more specific on that ?
If you think of pulseaudio as the sound server, i'm afraid a native 
pulse plugin will have to be written for good bluetooth support anyway.

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Marcel Holtmann]

Hi Fabien,

> >> Ok, then we have to implement snd_pcm_get_delay() and offer the option 
> >> to the application to sleep itself (or do other time consuming tasks 
> >> such as video decoding). However when the application sends data too 
> >> fast (such as a simple aplay) we *have* to do the sleeping ourselves to 
> >> prevents cuts on the headset side :-)
> > 
> > Aplay is not sending the data too fast. aplay tries to fill the sound
> > card buffer as 100% of sound playing application do.
> > Buffer size being known, delay determine available space. When there is
> > space, aplay writes data and that's all.
> > 
> > The current plugin delay implementation is the number of data written
> > (not played) => delay is always 0 => buffer is always empty => aplay
> > fills it => plugin have to wait in the write() call.
> > 
> 
> Ok, this time i understood. I agree with you. Which means two things:
>   * i basically screwed up the pcm plugin i did a while ago for headsetd 
> :-(. I was wrongs about the sleeping stuff. I understood alsa dynamic 
> behaviour the wrong way.
>   * ALSA API has the builtin assomption that the data gets transmitted 
> using a hardware ring buffer, which is not the bluetooth way of things 
> when you send packets one after the other.
> 
> This means we have to workaround this by implementing a virtual buffer 
> with a virtual hardware pointer.
> While as Marcel, i'm not a big fan of threads, i'd tend to see them here 
> as the less worse alternative we have :-) : so i'd say : let's go with 
> threads !!

just a small correction. I hate threads. However since ALSA already uses
them, we can do, too. Otherwise you would never convince me to use
threads.

> > In fact, the only application to care about is the sound server.
> 
> Could you be more specific on that ?
> If you think of pulseaudio as the sound server, i'm afraid a native 
> pulse plugin will have to be written for good bluetooth support anyway.

That is the plan in the end. Having a native PulseAudio plugin that
connects over our IPC to the audio service.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Fabien Chevalier]

> just a small correction. I hate threads. However since ALSA already uses
> them, we can do, too. Otherwise you would never convince me to use
> threads.

I hate them too, however not at the point not to use them when they 
sound like the only reasonable solution :-)

> 
>>> In fact, the only application to care about is the sound server.
>> Could you be more specific on that ?
>> If you think of pulseaudio as the sound server, i'm afraid a native 
>> pulse plugin will have to be written for good bluetooth support anyway.
> 
> That is the plan in the end. Having a native PulseAudio plugin that
> connects over our IPC to the audio service.

Sounds like a good plan !

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Frederic Dalleau]

> * ALSA API has the builtin assomption that the data gets transmitted 
> using a hardware ring buffer, which is not the bluetooth way of things 
> when you send packets one after the other.

Right, this is quite simple to emulate by doing this I got the best
experience with all players in a2dpd.

> This means we have to workaround this by implementing a virtual buffer 
> with a virtual hardware pointer.

A buffer, with a hardware pointer... data not sent yet must be stored.

> > I'm not sure we can assume an headset will buffer the received packets.
> 
> Well it does. However how much is left completely unspecified by the 
> bluetooth specs. :-(

Keep in mind that buffering induce latency. A2DP itself is not so
latent, my old iphono works great on windows , even for gaming... It
does not buffer data and requires precise timing.

The "all in plugin" architecture is designed to reduce data copy and
latency. If buffering starts to occur on headset side, then it seems to
me that all the benefit of this architecture are ruined.

> > In fact, the only application to care about is the sound server.
> 
> Could you be more specific on that ?

I don't think of a server in particular, it's difficult to choose one
yet...

It is time for me to leave.

Frederic


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Fabien Chevalier]

Hi Marcel, please find some comments bellow

>>> Otherwise the audio sounds too fast or frames are skipped. If you have
>>> any ideas on how we can improve pcm_bluetooth.c (yes, that handling is
>>> inside the ALSA plugin), I would like to know.
>> The issue you plotted here is a well known issue. Basically a2dp/avdtp 
>> profile does not specify how flow control is supposed to be handled, 
>> which leaves it open to implementation-specific behaviours (play faster, 
>> drop samples, use l2cap flow control...). :-(
>> The way handset makers have solved the issue is to throttle the data 
>> sending, to avoid triggering moonlight specific headset behaviours.
>> What i would suggest is to do the same thing using usleep() calls inside 
>> the alsa plugin.
> 
> we have to calculate the actual time of an SBC frame and then transmit
> it and then sleep the rest of the time before sending the next frame.
> However to have at least a little bit buffer, we should encode something
> around 3 L2CAP packets ahead. Should be something like 9-12 SBC frames.

The "something around 3 l2CAP packets" is what is called the buffer size 
in ALSA terminology. ;-)

> 
>> That will trigger another issue which is clock drifting, because the 
>> headset will supposedly consume data at master clock speed, while we 
>> will send data at host clock speed. I think for this one the best is to 
>> calculate and compensate for the drift using OCF_READ_CLOCK_OFFSET hci 
>> command: however it's just my wild guess ... ;-)
> 
> I can't see how the clock offset will help us here. It is only important
> for paging devices. All the other time, the device will re-sync their
> clocks as needed.

Ok, i will try to be more explicit then. I think you haven't catched the 
issue... yet ;-)
If you remember some of the electronics courses you certainly had, all 
electronics systems clocks are generated using quartz oscillator. Issue 
is those quartz, even if clocked officially at the same frequency, all 
beat at their own frequency.
Bluetooth spec choose to solve this issue by having the master send it's 
clock as a field of each packet sent to a slave. This way the slave is 
able to update in real time a register that stores the delta between the 
slave clock and the master clock. So each slave has an estimate of the 
master clock.
Now to come back to our streaming issues : the target is as follows.
* The A2DP headset has a unique quartz that powers both the bluetooth 
baseband and the sbc decoder/DAC part. (this is a guess, but i don't see
headset manufacturers put two quartz, as that would cost them more ;-))
* We have a usb or rs232 attached bluetooth dongle that is clocked by 
its own quartz.
* We have a main CPU whose time tracking functions are implemented using 
a timer interrupt that is based on its own quartz.

To prevent underrun audio cuts (data sent too slowly) or overrun audio 
cuts (data sent two fast), we must sent them at the *right* speed, which 
means the master clock's speed.
As the main CPU clock and the bluetooth master clock will inevitably 
drift (up to 250 ppm for the bluetooth master clock), we will have to 
compensate in software (which means in the alsa plugin). I suggest using 
the above given HCI command to retrieve the master clock.

I hope this is more clear :-)

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Marcel Holtmann]

Hi Fabien,

> >> That will trigger another issue which is clock drifting, because the 
> >> headset will supposedly consume data at master clock speed, while we 
> >> will send data at host clock speed. I think for this one the best is to 
> >> calculate and compensate for the drift using OCF_READ_CLOCK_OFFSET hci 
> >> command: however it's just my wild guess ... ;-)
> > 
> > I can't see how the clock offset will help us here. It is only important
> > for paging devices. All the other time, the device will re-sync their
> > clocks as needed.
> 
> Ok, i will try to be more explicit then. I think you haven't catched the 
> issue... yet ;-)
> If you remember some of the electronics courses you certainly had, all 
> electronics systems clocks are generated using quartz oscillator. Issue 
> is those quartz, even if clocked officially at the same frequency, all 
> beat at their own frequency.
> Bluetooth spec choose to solve this issue by having the master send it's 
> clock as a field of each packet sent to a slave. This way the slave is 
> able to update in real time a register that stores the delta between the 
> slave clock and the master clock. So each slave has an estimate of the 
> master clock.
> Now to come back to our streaming issues : the target is as follows.
> * The A2DP headset has a unique quartz that powers both the bluetooth 
> baseband and the sbc decoder/DAC part. (this is a guess, but i don't see
> headset manufacturers put two quartz, as that would cost them more ;-))
> * We have a usb or rs232 attached bluetooth dongle that is clocked by 
> its own quartz.
> * We have a main CPU whose time tracking functions are implemented using 
> a timer interrupt that is based on its own quartz.
> 
> To prevent underrun audio cuts (data sent too slowly) or overrun audio 
> cuts (data sent two fast), we must sent them at the *right* speed, which 
> means the master clock's speed.
> As the main CPU clock and the bluetooth master clock will inevitably 
> drift (up to 250 ppm for the bluetooth master clock), we will have to 
> compensate in software (which means in the alsa plugin). I suggest using 
> the above given HCI command to retrieve the master clock.

I might be simply never hear the difference, but anyway, we can actually
do this. However the implementation is tricky. The plugin should not
send HCI commands at all. Actually no daemon (except hcid) should send
any HCI commands at any time. I can make the kernel to as for the clock
offset in a certain interval. This costs too since it has to go over the
same HCI link that the audio data goes. So at which rate do you need
this information?

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Gnome Protocol Analyzer

[tjoconno]

I noticed on the last bluetooth gnome release there was a bluetooth
protocol analyzer gui included.

Under import connections, how is it possible to import a connection from a
local or remote device? Can you import directly from a LeCroy or Frontline
Bluetooth Protocol Analyzer? Can you import directly from standard
bluetooth dongles?

Thank you.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Fabien Chevalier]

Hi Marcel,

> 
> I might be simply never hear the difference, 

Well, you will, however not always, this will be dependant upon the 
bluetooth devices used, so that might work for you but fail for someone 
else if those clock drifting issues are not handled properly.

but anyway, we can actually
> do this. However the implementation is tricky. The plugin should not
> send HCI commands at all. Actually no daemon (except hcid) should send
> any HCI commands at any time. 

Woops, didn't know about that :-(

Are there any hard constraints behing this limitation or is it just a 
good software architecturing rule that prevents us from doing it ?

> I can make the kernel to as for the clock
> offset in a certain interval. 
Just for my own comprehension : could you expose here how do you intend 
to implement this ?

> This costs too since it has to go over the
> same HCI link that the audio data goes. 
Agreed :-)
> So at which rate do you need
> this information?

Let's say we are unlucky and we got the master clock and the main CPU 
clock to drift each of 250 ppm in opposite directions. That leaves use 
with a 30 ms per minute drift.

I'd say a clock resynch every 20-30 seconds should be enough, and would 
limit the drift at any time below 15 mseconds, which should be 
compensated byt the headset side buffering.

So let's say i need this information every ~20 seconds.

Note : of course this is for a2dp only, sco matters are completely 
different.

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Marcel Holtmann]

Hi Fabien,

> > I might be simply never hear the difference, 
> 
> Well, you will, however not always, this will be dependant upon the 
> bluetooth devices used, so that might work for you but fail for someone 
> else if those clock drifting issues are not handled properly.
> 
> but anyway, we can actually
> > do this. However the implementation is tricky. The plugin should not
> > send HCI commands at all. Actually no daemon (except hcid) should send
> > any HCI commands at any time. 
> 
> Woops, didn't know about that :-(
> 
> Are there any hard constraints behing this limitation or is it just a 
> good software architecturing rule that prevents us from doing it ?

currently it is not a hard requirement, but I am going to change that at
some point in the (far) future. The kernel is responsible for HCI. Our
interface actually is pretty sane since even commands from user space
are honored by the kernel and the flow control will be applied. However
in some corner cases (like hcitool cc for example) the kernel takes full
control and applies its rules. And the kernel is always right.

The other point is that only the kernel has enough knowledge to actually
trigger certain actions. All user space application have only a limited
view of HCI and thus it is a bad idea to mess around with it.

> > I can make the kernel to as for the clock
> > offset in a certain interval. 
> Just for my own comprehension : could you expose here how do you intend 
> to implement this ?

No idea, yet. Adding the scheduling of this command is really simple. A
problem is actually to get the result of it into the audio service. The
kernel knows it and hcid can easily get it, but that doesn't help us.

> > This costs too since it has to go over the
> > same HCI link that the audio data goes. 
> Agreed :-)
> > So at which rate do you need
> > this information?
> 
> Let's say we are unlucky and we got the master clock and the main CPU 
> clock to drift each of 250 ppm in opposite directions. That leaves use 
> with a 30 ms per minute drift.
> 
> I'd say a clock resynch every 20-30 seconds should be enough, and would 
> limit the drift at any time below 15 mseconds, which should be 
> compensated byt the headset side buffering.
> 
> So let's say i need this information every ~20 seconds.

Every 20 seconds is no problem. A kernel patch for that is rather simple
actually.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel