Ok, I didn't imagine better title for this curious bug, don't think this is an arecord problem, it might be a deeper problem in Openwrt.
Scenario: USB sound card installed in a MIPS BE router (bcm63xx), using OHCI module, alsa-utils installed. Let's make some recordings with arecord. arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test01.wav <-- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test02.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test03.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test04.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test05.wav <-- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test06.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test07.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test08.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test09.wav <-- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test10.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test11.wav <-- bad ...... As you can see, there is a pattern, after exactly 4 recordings it seems the audio card, or maybe unknown stuff at the system returns to a sane state where arecord can make a good job. I tested it dozen times, always with the same pattern: 1 good recording, 3 bad I suspected it might be an endianess problem, and decided to do the same in a LE device, this time bcm47xx, an asus wl500g-premium v1, using UHCI module for the usb audiostick. arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test01.wav <-- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test02.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test03.wav <-- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test04.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test05.wav <-- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test06.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test07.wav <-- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test08.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test09.wav <-- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test10.wav <-- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test11.wav <-- good The problem persists, but this time the pattern changed to 1 good, 1 bad recording In both cases I used the same last trunk revisions. But I noticed this problem is present long time ago in OpenWrt. It didn't happen in my x86 PC, and never found people complaining about this problem in x86 PCs where arecord is commonly used. Ok, I don't pretend to use arecord for anything. The problem is other apps are affected by this bug. I use LIRC (audio_alsa) connected to the microphone input to send IR commands with a remote, and sometimes works others don't. This was reported elsewhere by other people. So arecord is revealing a problem in OpenWrt. If you want to see how does look a bad or good recording, link: https://drive.google.com/folderview?id=0B-EMoBe-_OdBOXdPdTBaQTVOc00&usp=sharing They are button press with an IR remote. So, I have a simple question: What's going on? _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
