From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] encoding delay, librarifying a2play
Date: Sun, 28 Nov 2004 07:56:28 +0100 [thread overview]
Message-ID: <1101624988.18467.32.camel@pegasus> (raw)
In-Reply-To: <41A936C6.70209@xmission.com>
Hi Brad,
> I was able to encode audio in real time with:
>
> arecord -c 2 -r 44100 -f S16_BE -t au /dev/stdout | ./sbc/sbcenc - |
> ./a2play 00:08:F4:30:05:BB
>
> But I estimate the delay is about 300ms. The bluetake encoder dongle was
> bothering me with its delay which is probably under 200ms... I really
> want to get our encoder under 100ms. I read somewhere that 60ms is
> achievable.
>
> I think the place to start to get shorter latency is to write something
> that reads audio itself, uses the encoder library and writes out to the
> headset. Context switches between the 3 userland apps could be wiped
> out. I imagine the app will have command-line args for rate and mode,
> will open/ioctl the audio device appropriately, and then write to the
> headset.
the pipes and too small buffers can be really a problem here.
> What's the ultimate destination for a2play? A library somewhere? I need
> to break a2play into at least 3 files: headers, library, and a fairly
> simple main(). Is this a good time?
I propose a generic AVDTP library that will handle all AVDTP related
things. I checked in some basic code into the avdtp directory. My idea
is to make the library look like a socket interface so we can later move
things very easy to a kernel AVDTP implementation.
The a2play is then only a frontend for the AVDTP library, SBC library
and some audio input library (libmad for exmaple). And I think we should
also include the rcplay stuff into it and provide an alternate RFCOMM
streaming with an extra parameter.
However the final goal should be an ALSA library extension like their
JACK plugin. But from my first tests I realized that it is impossible to
create such an extension outside the ALSA PCM directory. I must talk
with the ALSA developers about that issue.
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://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2004-11-28 6:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-28 2:24 [Bluez-devel] encoding delay, librarifying a2play Brad Midgley
2004-11-28 6:56 ` Marcel Holtmann [this message]
2004-11-29 21:14 ` Brad Midgley
2004-11-29 21:45 ` 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=1101624988.18467.32.camel@pegasus \
--to=marcel@holtmann.org \
--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