From: Rob Sykes <aquegg@yahoo.co.uk>
To: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: pcm_rate API question
Date: Mon, 30 Sep 2013 12:15:13 +0100 (BST) [thread overview]
Message-ID: <1380539713.33591.YahooMailNeo@web171401.mail.ir2.yahoo.com> (raw)
In-Reply-To: <52493D77.40601@ladisch.de>
----- Original Message -----
> From: Clemens Ladisch <clemens@ladisch.de>
> To: alsa-devel@alsa-project.org
> Cc:
> Sent: Monday, 30 September 2013, 9:59
> Subject: Re: [alsa-devel] pcm_rate API question
>
>>> Typically there is some buffering/delay within a resampler -- how
>>> does the pcm_rate API allow for this?
>
> The API itself does not allow for this. Your code must generate
> dst_frames samples.
>
> At startup, prefix the output with zero samples. For example,
Thanks Clemens. Having to prefix the output with a signal that is unrelated to the input signal doesn't seem great, though I guess this just manifests itself as a delay (variable, dependent on resampler, etc.) and may go unnoticed. Of more concern is that this situation can apparently occur at any time: "after that first call all subsequent calls will probably get you about 2000 samples out for every 1000 samples you put in" — only "probably", not "always"; occurring after the start, this will likely cause audible distortion.
> The conversion indeed is not accurate, unless you are using a period
> size of an integer multiple of 441 frames. In your example, the
> application probably used a buffer of 0.5 s and four periods per buffer;
> it should either double the buffer size or halve the number of periods.
Oh okay, the application in question was aplay 1.0.25; maybe it's since been fixed, but no matter, it seems that the above buffering issue is the main problem.
Cheers,
Rob
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2013-09-30 11:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-27 11:59 pcm_rate API question Rob Sykes
2013-09-27 12:38 ` Clemens Ladisch
[not found] ` <1380295697.44147.YahooMailNeo@web171405.mail.ir2.yahoo.com>
2013-09-28 9:58 ` Rob Sykes
2013-09-30 8:59 ` Clemens Ladisch
2013-09-30 11:15 ` Rob Sykes [this message]
2013-09-30 14:16 ` Clemens Ladisch
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=1380539713.33591.YahooMailNeo@web171401.mail.ir2.yahoo.com \
--to=aquegg@yahoo.co.uk \
--cc=alsa-devel@alsa-project.org \
/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