[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