public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: "Luiz Augusto von Dentz" <luiz.dentz@gmail.com>
To: "BlueZ development" <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels
Date: Mon, 13 Aug 2007 23:39:43 -0300	[thread overview]
Message-ID: <2d5a2c100708131939k32d34dc7u9961aecc0c0cf624@mail.gmail.com> (raw)
In-Reply-To: <1187027354.6262.59.camel@ubuntu.mpl.access-company.com>

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

  reply	other threads:[~2007-08-14  2:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-11  9:48 [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels Fabien Chevalier
2007-08-11 18:01 ` Marcel Holtmann
2007-08-12 10:22   ` Fabien Chevalier
2007-08-13  9:59   ` Frederic Dalleau
2007-08-13 10:05     ` Marcel Holtmann
2007-08-13 15:54       ` Fabien Chevalier
2007-08-13 17:04         ` Marcel Holtmann
2007-08-13 17:49           ` Frederic Dalleau
2007-08-14  2:39             ` Luiz Augusto von Dentz [this message]
2007-08-14 12:51             ` Fabien Chevalier
2007-08-14 14:47               ` Frederic Dalleau
2007-08-14 16:40                 ` Marcel Holtmann
2007-08-17 10:42                 ` Fabien Chevalier
2007-08-17 11:06                   ` Marcel Holtmann
2007-08-18 14:13                     ` Fabien Chevalier
2007-08-17 13:41                   ` Frederic Dalleau
2007-08-14 12:51           ` Fabien Chevalier
2007-08-14 16:44             ` Marcel Holtmann
2007-08-14 19:31               ` [Bluez-devel] Gnome Protocol Analyzer tjoconno
2007-08-17 11:17               ` [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels Fabien Chevalier
2007-08-17 11:32                 ` Marcel Holtmann

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=2d5a2c100708131939k32d34dc7u9961aecc0c0cf624@mail.gmail.com \
    --to=luiz.dentz@gmail.com \
    --cc=bluez-devel@lists.sourceforge.net \
    /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