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

[Frederic Dalleau <frederic.dalleau@access-company.com>]

> * 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