This is a regression between 2.6.35 and 2.6.36. In 2.6.36, running "arecord" with a specified duration hangs and no sound is written to the output file. The symptomatic command is: arecord -d 2 testfile.wav Similar behaviour is observed with the SOX "rec" command: rec testfile.wav trim 0 2 I have bisected the problem down to the commit: commit eb541337b7a43822fce7d0c9d967ee149b2d9a96 Author: Takashi Iwai <tiwai@suse.de> Date: Fri Aug 6 13:48:11 2010 +0200 ALSA: hda - Make converter setups sticky So far, we reset the converter setups like the stream-tag, the channel-id and format-id in prepare callbacks, and clear them in cleanup callbacks. This often causes a silence of the digital receiver for a couple of seconds. This patch tries to delay the converter setup changes as much as possible. The converter setups are cached and aren't reset as long as the same values are used. At suspend/resume, they are cleared to be recovered properly, too. Signed-off-by: Takashi Iwai <tiwai@suse.de> I have attached the output of the alsa-info.sh script from either side of the above commit. Also included are straces from arecord in both cases.
Created attachment 35682 [details] output from alsa-info.sh after applying the problematic commit
Created attachment 35692 [details] output from alsa-info.sh before applying the problematic commit The only non-trivial differences appear to be the "Converter:" fields of some of the "nodes" in "!!HDA-Intel Codec information".
Created attachment 35702 [details] strace arecord -d 2 /dev/null > bad.strace 2>&1
Created attachment 35712 [details] strace arecord -d 2 /dev/null > good.strace 2>&1
The problem for AD codecs should have been fixed by commit 0e7adbe263f89ea2ef15b5af5e80a812b2a85025. It'll be included in stable 2.6.35 tree later.
Created attachment 35772 [details] output from alsa-info.sh on mainline (with 0e7adbe263f89ea2ef15b5af5e80a812b2a85025) Sorry, forgot to mention that this persists in the current mainline (i.e, 0e7adbe263f89ea2ef15b5af5e80a812b2a85025 is applied, but it's still hanging). alsa-info.sh does however show converter info consistent with "good".
Weird. To make sure that it's because of sticky PCM changes, could you revert the following commits from 2.6.36? 3f50ac6a0ec80a83a1a033fe5004fb319ad72db7 f0cea79724f03ee55e7b5933b6a6f6a3fd177710 eb541337b7a43822fce7d0c9d967ee149b2d9a96
These reverts appear to be nontrivial. I won't be able to check this out for another day or two.
Sorry, it quickly became a lot more than a couple days. I realised the reverts were in fact trivial. I'm not sure exactly why I thought they weren't. In any case, applying all three reverts to v2.6.36 gave (almost) expected behaviour. The only hitch was that on the first record after boot or resume from suspend: $ arecord -d 2 testfile.wav Recording WAVE 'testfile.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono overrun!!! (at least -1302854201999.987 ms long) Further records worked without event.
I should add that in spite of the overrun message, the first record described in comment #9 is successful. As for the more current situation: With e38f5b745075828ac51b12c8c95c85a7be4a3ec7 ~ 2.6.39-rc3, I find that the first attempt to record after boot or resume from suspend fails as described in the original bug description. However, if I interupt that first record with Ctrl-C, further records succeed.
Does the problem still happen with 3.12 kernel?
It looks to be fixed at least as far back as 3.2. Thanks for keeping this opened and sorry for the delay, but the machine in question is no longer running at the bleeding edge. The problem is no longer present with the debian version of 3.2 or 3.10. It seems 3.12 onwards has unrelated boot time graphics problems on that machine, so I couldn't test it out there, but I think its safe to call this "fixed".