From: Jaroslav Kysela <perex@perex.cz>
To: Daniel Drake <drake@endlessm.com>, alsa-devel@alsa-project.org
Subject: Re: arecord: strange --duration behaviour with some sample rates
Date: Tue, 20 Jan 2015 21:51:00 +0100 [thread overview]
Message-ID: <54BEBFB4.1050901@perex.cz> (raw)
In-Reply-To: <CAD8Lp47AoypMz_AYicOh7XvCThc-xKwxa2NYMRD_3h-aOophbA@mail.gmail.com>
Dne 20.1.2015 v 21:38 Daniel Drake napsal(a):
> Hi,
>
> With alsa-utils-1.0.28, we're seeing some strange behaviour when running:
> arecord -t wav -r 44100 -d 1 out.wav
>
> After recording 1 second of data to out.wav, a load of extra files are
> created like out-01.wav, out-02.wav, out-03.wav, etc. These extra
> files are 44 bytes in length. arecord seems to continue like this
> forever rather than exiting after the 1 second recording.
>
> The problem is somehow linked to the sample-rate. At 48000 or 8000,
> things work fine, just 44100 is bad.
>
> Tracing some values in the source:
> count is 44100, and rest is initialized to the same.
>
> In each iteration of the /* capture */ loop, f has value 5512, i.e.
> 5512 bytes are read.
> So rest decreases through values 38588, 33076, 27564, 22052, 16540, 11028, 5516.
>
> Now we read another 5512 bytes, rest is decreased to 4.
> So we now call pcm_read(audiobuf, f) where f has value 4.
> pcm_read adjusts that to 5512 and returns 5512.
>
> Now we hit:
> if (pcm_read(audiobuf, f) != f)
> break;
>
> We break out of that inner loop, count still has value 4 so we reach
> the end of the outer loop, and loop again, which causes a new file to
> be opened, etc.
>
> Sorry that I'm not quite up-to-scratch with pcm basics to suggest a
> quick fix, but hopefully this diagnosis is useful at least.
Hi,
the fix is here:
http://git.alsa-project.org/?p=alsa-utils.git;a=commit;h=8f361d83cfcb39887f5fc591633e68d9448e3425
Jaroslav
--
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
prev parent reply other threads:[~2015-01-20 20:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 20:38 arecord: strange --duration behaviour with some sample rates Daniel Drake
2015-01-20 20:51 ` Jaroslav Kysela [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=54BEBFB4.1050901@perex.cz \
--to=perex@perex.cz \
--cc=alsa-devel@alsa-project.org \
--cc=drake@endlessm.com \
/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;
as well as URLs for NNTP newsgroup(s).