* [Bluez-devel] a2dp timing
@ 2005-03-25 5:00 Brad Midgley
2005-03-25 13:14 ` Marcel Holtmann
0 siblings, 1 reply; 11+ messages in thread
From: Brad Midgley @ 2005-03-25 5:00 UTC (permalink / raw)
To: BlueZ Mailing List
Hi
We've had problems with a2dp timing that I've been ignoring.
For one, a2play crams frames into the headset just as fast as it can.
Sometimes this is too fast. So we need to clock it so things are
staggered properly. Does the SBC encoder give us a clue about timing
between frames?
Second, if the headset wanders out of range, the player stops and starts
up where it left off when the headset is back. If we're pacing things
properly, we need to drop frames instead when this happens. I'm thinking
if it results in a legal SBC stream that I'll drop entire SBC frames in
the main loop with something like:
frame_len = read_header(fd, &sbc_info);
bytes_read = read(fd, killbuffer, frame_len);
Are there other timing issues I need to think about? Does it get so
messy that I need to watch jitter? I can only vaguely remember this
stuff from my networking classes...
Brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-devel] a2dp timing
2005-03-25 5:00 [Bluez-devel] a2dp timing Brad Midgley
@ 2005-03-25 13:14 ` Marcel Holtmann
2005-03-25 14:22 ` Guylhem Aznar
2005-03-25 16:44 ` Brad Midgley
0 siblings, 2 replies; 11+ messages in thread
From: Marcel Holtmann @ 2005-03-25 13:14 UTC (permalink / raw)
To: BlueZ Mailing List
Hi Brad,
> We've had problems with a2dp timing that I've been ignoring.
>
> For one, a2play crams frames into the headset just as fast as it can.
> Sometimes this is too fast. So we need to clock it so things are
> staggered properly. Does the SBC encoder give us a clue about timing
> between frames?
it would be really great to get a FTS or CATC trace from the HP
headphone and the iPAQ for example.
In the case of an ALSA plugin, we may simple use the timing of the ALSA
system itself. However it would be great if the SBC encoder would also
calculate the time of the PCM fragment.
> Second, if the headset wanders out of range, the player stops and starts
> up where it left off when the headset is back. If we're pacing things
> properly, we need to drop frames instead when this happens. I'm thinking
> if it results in a legal SBC stream that I'll drop entire SBC frames in
> the main loop with something like:
>
> frame_len = read_header(fd, &sbc_info);
> bytes_read = read(fd, killbuffer, frame_len);
And then you need to sleep some time before reading/dropping the next
SBC frame.
> Are there other timing issues I need to think about? Does it get so
> messy that I need to watch jitter? I can only vaguely remember this
> stuff from my networking classes...
I don't think that this will be needed, but we will see.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-devel] a2dp timing
2005-03-25 13:14 ` Marcel Holtmann
@ 2005-03-25 14:22 ` Guylhem Aznar
2005-03-25 14:26 ` Marcel Holtmann
2005-03-25 16:44 ` Brad Midgley
1 sibling, 1 reply; 11+ messages in thread
From: Guylhem Aznar @ 2005-03-25 14:22 UTC (permalink / raw)
To: bluez-devel
On Friday, 25 March 2005 at 14:14:36 (+0100), Marcel Holtmann wrote:
> it would be really great to get a FTS or CATC trace from the HP
> headphone and the iPAQ for example.
Please tell me how to do it. I will be happy to help.
However I don't have the bluesoleil stack....
--=20
Bien =E0 vous - Best regards,
Guylhem P. Aznar
--=20
*@externe.net http://externe.n=
et
P=E9rim=E9/Deprecated: @oeil.qc.ca, @metalab.unc.edu, @ibiblio.org, @7=
un.org
GPG: 92EB37C1 DD11C9C9 20519D01 E8FA1B11 42975AF7 http://externe.net/pubk=
ey
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-devel] a2dp timing
2005-03-25 13:14 ` Marcel Holtmann
2005-03-25 14:22 ` Guylhem Aznar
@ 2005-03-25 16:44 ` Brad Midgley
2005-03-25 17:31 ` Marcel Holtmann
1 sibling, 1 reply; 11+ messages in thread
From: Brad Midgley @ 2005-03-25 16:44 UTC (permalink / raw)
To: bluez-devel
Marcel
> In the case of an ALSA plugin, we may simple use the timing of the ALSA
> system itself. However it would be great if the SBC encoder would also
> calculate the time of the PCM fragment.
ok, I will look at the plugin again. I was discouraged before by the
complexity and by the fact that a lot of alsa clients won't let you
choose a userspace plugin device (and even with those that do, you have
to remember and type in an alsa device name to reach a userspace plugin)
>> frame_len = read_header(fd, &sbc_info);
>> bytes_read = read(fd, killbuffer, frame_len);
>
> And then you need to sleep some time before reading/dropping the next
> SBC frame.
of course from the plugin, these won't be read() calls, they will be
calls into the sbc lib.
brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-devel] a2dp timing
2005-03-25 16:44 ` Brad Midgley
@ 2005-03-25 17:31 ` Marcel Holtmann
2005-04-04 17:14 ` Brad Midgley
0 siblings, 1 reply; 11+ messages in thread
From: Marcel Holtmann @ 2005-03-25 17:31 UTC (permalink / raw)
To: BlueZ Mailing List
Hi Brad,
> > In the case of an ALSA plugin, we may simple use the timing of the ALSA
> > system itself. However it would be great if the SBC encoder would also
> > calculate the time of the PCM fragment.
>
> ok, I will look at the plugin again. I was discouraged before by the
> complexity and by the fact that a lot of alsa clients won't let you
> choose a userspace plugin device (and even with those that do, you have
> to remember and type in an alsa device name to reach a userspace plugin)
the flag for that is there, but the ALSA core does not use it. Seems
like I need to remind Takashi to add it.
> >> frame_len = read_header(fd, &sbc_info);
> >> bytes_read = read(fd, killbuffer, frame_len);
> >
> > And then you need to sleep some time before reading/dropping the next
> > SBC frame.
>
> of course from the plugin, these won't be read() calls, they will be
> calls into the sbc lib.
In case of the plugin you can simply drop the PCM fragment.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-devel] a2dp timing
2005-03-25 17:31 ` Marcel Holtmann
@ 2005-04-04 17:14 ` Brad Midgley
2005-04-05 15:12 ` Marcel Holtmann
0 siblings, 1 reply; 11+ messages in thread
From: Brad Midgley @ 2005-04-04 17:14 UTC (permalink / raw)
To: bluez-devel
Marcel
FYI, I found alsa-lib post-1.0.8 has fixed up the plugin api so plugins
really can be built standalone. The plugins were moved to a different
cvs project "alsa-plugins" and the api changed in the process.
I changed our reference plugin to be based on the new oss plugin. I will
work on the a2dp source side of things here. It looks much more
straightforward now.
I suppose we could implement a2dp sink as well, but I don't think
connections can be initiated by a sink--it has to listen for the source
to make the connection.
I'm keeping the cvs code up to date in case anyone wants to look (in
btsco/bt)
On a more pragmatic note, I sold my bluetake to a friend so it won't be
as easy to try things on it. I bought one of the iTech sets so hopefully
development can go well with the new headset.
Brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-devel] a2dp timing
2005-04-04 17:14 ` Brad Midgley
@ 2005-04-05 15:12 ` Marcel Holtmann
0 siblings, 0 replies; 11+ messages in thread
From: Marcel Holtmann @ 2005-04-05 15:12 UTC (permalink / raw)
To: bluez-devel
Hi Brad,
> FYI, I found alsa-lib post-1.0.8 has fixed up the plugin api so plugins
> really can be built standalone. The plugins were moved to a different
> cvs project "alsa-plugins" and the api changed in the process.
I know and actually the utils CVS already contains a plugin for SBC over
RFCOMM. Was a simple proof-of-concept thing.
> On a more pragmatic note, I sold my bluetake to a friend so it won't be
> as easy to try things on it. I bought one of the iTech sets so hopefully
> development can go well with the new headset.
I think we really need the Logitech/HP headphone for further development
and so if anyone wants to support this, do a PayPal donation and then I
will buy one for Brad and me.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-04-05 15:12 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-25 5:00 [Bluez-devel] a2dp timing Brad Midgley
2005-03-25 13:14 ` Marcel Holtmann
2005-03-25 14:22 ` Guylhem Aznar
2005-03-25 14:26 ` Marcel Holtmann
2005-03-25 17:23 ` Guylhem Aznar
2005-03-25 17:28 ` Marcel Holtmann
2005-03-25 18:14 ` btlog anyone? " Brad Midgley
2005-03-25 16:44 ` Brad Midgley
2005-03-25 17:31 ` Marcel Holtmann
2005-04-04 17:14 ` Brad Midgley
2005-04-05 15:12 ` Marcel Holtmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox