Andy Green <[email protected]> writes: > On 11/01/13 09:19, the mail apparently from Michael Hudson-Doyle included: >> Dave Pigott <[email protected]> writes: >> >>> On 7 Jan 2013, at 09:46, Andy Green <[email protected]> wrote: >>> >>>> On 07/01/13 17:36, the mail apparently from Dave Pigott included: >>>>> Hi Andy, >>>>> >>>>> One other question: >>>>> I assume you'll be wanting audio in and out available? On the panda, >>>>> which is which? I can't seem to find any documentation on that. :) >>>> >>>> It's the bottom connector that is the output from the Panda and the top >>>> connector that's the input to the Panda. >>> >>> Given a 50/50 chance, I happened to get it the right way first time. :) >> >> So I've tried to run my test in the lab now, but it seems that it's not >> possible to capture audio from the device on the host. The other way >> around works fine -- I can capture audio on pandaes-02 that was played >> on the host -- but not device->host. I just get silence, or very near >> it: >> >> http://validation.linaro.org/lava-server/dashboard/streams/private/team/linaro/mwhudson-audio/bundles/fb40806759453f1650756e98044f2201173b2d51/9b8c3255-4c29-4c95-9915-a7e2435dca36/result/2/ >> >> (there is a touch of low frequency noise). >> >> I guess audio out in the image I'm using >> (http://snapshots.linaro.org/quantal/pre-built/panda/43/panda-quantal_developer_20130109-43.img.gz) >> could just be broken -- is this possible? -- or the cable could be >> loose, or something else entirely. I guess I'd appreciate it if Dave >> could check the cabling :-) >> >> Is there a known good image I could be using? > > If it's even halfway modern don't think there'll be any problem with > the Panda audio side in terms of being broken... it has been stable for > many months now on 3.4. > > It's more likely to do with input source routing for audio on your > host.
Ah yes, seems you are right. I'd poked around in alsamixer on the device but not on the host. > Assuming it's physically cabled from the Panda audio out to the "Line > In" you will need to select that input source on the host. > > Alsamixer can do it over ssh, alsamixer -c1 (-c<n> selects card n), hit > tab to see input sources. User cursor keys to select "Line In". Hit > space to make it the capture channel, set levels with up/down keys. It seems the capture channel was the mic input not the line in. I changed that and I got better results: http://validation.linaro.org/lava-server/dashboard/streams/private/team/linaro/mwhudson-audio/bundles/11850d570105c389609c1689edace742a9e78fbb/f7cb7bf6-82af-4d0b-bf48-4714c18ecf84/result/2/ but lava-fft still doesn't like the rec.wav: + lava-fft -t 1 -i -s 0.25 + tee results.log Failed to see enough leadin silence 36817 376 Looking at the file in audacity, there is a click at about 0.77s in and if I snip that out I get: Skipping to +2.141708s in capture Ch 0: 0.010824 0.011 which seems like a reasonable figure of merit. So progress, but not yet success -- do you know what might be going on here? Hopefully it's just a level problem in the alsa settings or something. > Assuming it works after a sufficiency of meddling, you can use alsactl > store / restore <card #> to capture to and restore from a file to automate. If I read the runes correctly, it looks like ubuntu preserves alsa settings over reboots, so once we've got the settings right we could just leave them there. It's probably better to be more paranoid though -- maybe the device config should point to the path of an alsa config file that could be applied before each test is run or something along those lines. Cheers, mwh _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
