From: James Courtier-Dutton <James@superbug.co.uk>
To: Juan Zapatero <jazc@gmvsistemas.es>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: Writing a Full-Duplex (capture/playback) application.
Date: Fri, 23 Dec 2005 14:59:36 +0000 [thread overview]
Message-ID: <43AC10D8.2050609@superbug.co.uk> (raw)
In-Reply-To: <1135338946.22198.9.camel@jazc.fedora>
Juan Zapatero wrote:
>>When doing full duplex, do not open the device as full duplex, open the
>>device twice. Once for playback and once for capture. The reason for
>>this is that sound cards often have different buffer sizes for capture
>>and playback, and so separating them gives you more control over buffer
>>and period sizes.
>>For playback use device name "plug:front", for capture you can use the
>>same "plug:front". The important bit it the "plug", as it will do sample
>>rate and sample format conversion for you.
>>For low latency application like voice, it is actually better to sample
>>at high frequencies, e.g. 48000Hz. You then do the sample rate
>>conversion in your application. This way, not only is the sample rate
>>conversion much higher quality than alsa-lib can probably do, it can
>>also be optimised for your application. e.g. VoIP usually uses 20ms of
>>voice per packet. You can create a very efficient block sample rate
>>converter when taking all 20ms into account.
>>There is also an option in the api to force the "plug" layer to do
>>sample format conversion, but not sample rate conversion, thus ensuring
>>that alsa-lib does not do any sample rate conversion, leaving your
>>application to do it.
>>
>>James
>
> The problem about sample rate is that I need the captured audio to be as
> much compressed as possible so that I can get it trough a GPRS link.
> That's why I use 8000Hz, 16bit, and I would like to capture in Mono,
> because there is no sense in capturing stereo channels with a mono
> microphone.
>
>
My point is that you capture at 48000Hz, you then resample down to
8000Hz in your software ready for the GPRS link.
You improve the latency that way.
James
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
prev parent reply other threads:[~2005-12-23 14:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-22 9:25 Writing a Full-Duplex (capture/playback) application Juan Zapatero
2005-12-22 17:43 ` Steve deRosier
2005-12-23 9:39 ` Juan Zapatero
2005-12-23 10:57 ` James Courtier-Dutton
2005-12-23 11:55 ` Juan Zapatero
2005-12-23 14:59 ` James Courtier-Dutton [this message]
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=43AC10D8.2050609@superbug.co.uk \
--to=james@superbug.co.uk \
--cc=alsa-devel@lists.sourceforge.net \
--cc=jazc@gmvsistemas.es \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.