Hi all,
I've got the i.tech A2DP stereo headset clip-y thing. I've gotten a2play
working, but the sound skips every several seconds while playing. I
tried the -p flag, and that helped a whole lot, bringing the
time-between-skips up to over a minute, but it still happens, and it's
still annoying.
Looking at how things work, I get the idea that the sender just blasts
out data with no way to check on the buffer of the receiver. Could it
just be that the i.tech headset doesn't handle something right? Or is
this likely a timing issue on the computer? Should I just start tossing
in other numbers, like 43995 or 44005? Any other clues?
Further, if anyone is interested, an i.tech clip can be modified into
having a low-level output to something like an amp (in my case, my car
radio) with just a little bit of soldering. Further, since it uses
standard nokia chargers, you can hook it up to run off of 12v with a
nokia car charger (available at any quality computer show).
Thanks for any help,
Scott Gilliland
Scott Gilliland at gatech dot edu
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Scott
ironically, when the encoder was a little slower, i could do no wrong
when streaming to my itech. only after speeding it up did it become
essential to pace things better.
sure, you can try fine-tuning but i believe the real problem will be
solved by completing a plugin. gstreamer looks promising in this
arena... each chunk of data has timing info attached and i assume the
library provides additional help.
i'm hoping gstreamer can help on another timing issue... latency. maybe
by telling the system to build the appropriate delay into the video side
of multimedia. try watching video with a2dp audio and you'll quickly get
annoyed with the delay.
brad
> I've got the i.tech A2DP stereo headset clip-y thing. I've gotten a2play
> working, but the sound skips every several seconds while playing. I
> tried the -p flag, and that helped a whole lot, bringing the
> time-between-skips up to over a minute, but it still happens, and it's
> still annoying.
>
> Looking at how things work, I get the idea that the sender just blasts
> out data with no way to check on the buffer of the receiver. Could it
> just be that the i.tech headset doesn't handle something right? Or is
> this likely a timing issue on the computer? Should I just start tossing
> in other numbers, like 43995 or 44005? Any other clues?
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Scott
> Thanks the the info. Just a question or two... Are you saying that
> timing information actually makes it all the way out to the headset? I
> assumed it was just raw data, and the headset just tried to play it at
> the appropriate speed. (the headset could then vary a bit depending on
> how full the buffer was)
In order to keep latency down, the headset should not be buffering much;
it just plays stuff when it arrives. Unfortunately, in the current
headsets, we get the effects of no buffer *and* significant latency. :(
> Also, yes, the idea of having the latency info fed back to the source
> had occurred to me as well. Is there any way at all to estimate the
> delay from the headset tho? or would it just have to be a value you tune
> manually? Also, do you know if gstreamer is able to do this kind of
> thing now?
I don't know if gstreamer will do this.
I think we'd have to keep a table of typical latencies based on the
identity of the set. Bluecore03-mm probably has the same latency across
every set that uses it for example.
Brad
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad,
Thanks the the info. Just a question or two... Are you saying that
timing information actually makes it all the way out to the headset? I
assumed it was just raw data, and the headset just tried to play it at
the appropriate speed. (the headset could then vary a bit depending on
how full the buffer was)
Also, yes, the idea of having the latency info fed back to the source
had occurred to me as well. Is there any way at all to estimate the
delay from the headset tho? or would it just have to be a value you tune
manually? Also, do you know if gstreamer is able to do this kind of
thing now?
Thanks again,
Scott
On Tue, 2006-02-28 at 23:18 -0700, Brad Midgley wrote:
> Scott
>
> ironically, when the encoder was a little slower, i could do no wrong
> when streaming to my itech. only after speeding it up did it become
> essential to pace things better.
>
> sure, you can try fine-tuning but i believe the real problem will be
> solved by completing a plugin. gstreamer looks promising in this
> arena... each chunk of data has timing info attached and i assume the
> library provides additional help.
>
> i'm hoping gstreamer can help on another timing issue... latency. maybe
> by telling the system to build the appropriate delay into the video side
> of multimedia. try watching video with a2dp audio and you'll quickly get
> annoyed with the delay.
>
> brad
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel