[alsa-devel] arecord: strange --duration behaviour with some sample rates
Jaroslav Kysela
perex at perex.cz
Tue Jan 20 21:51:00 CET 2015
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 at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
More information about the Alsa-devel
mailing list