BeagleboardRevCValidation - what actually works?

I've gone through most of the validation as described at:
  http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidation

Audio playback seemed to go fine, but I ran into some issues with the
audio recording, where it was reporting overrun errors. After doing
some research, I've found that this is not an unknown issue with the
audio on the BB. Which of the validation tests are working and which
are not? Can the content of the page be updated to highlight those
things that aren't working in the validation image?

If it's being put out there for people to verify that their hardware
is working, shouldn't it work, or at least say which things are not so
that we don't think our boards are broken?

I've gone through most of the validation as described at:
Google Code Archive - Long-term storage for Google Code Project Hosting.

Audio playback seemed to go fine, but I ran into some issues with the
audio recording, where it was reporting overrun errors. After doing
some research, I've found that this is not an unknown issue with the
audio on the BB. Which of the validation tests are working and which
are not? Can the content of the page be updated to highlight those
things that aren't working in the validation image?

Audio recording should work as well, you might get a burst while you
play back but that should be fine

If it's being put out there for people to verify that their hardware
is working, shouldn't it work, or at least say which things are not so
that we don't think our boards are broken?

Every thing documented should work as is, with out any changes. Let me
know if some things are not working for you.

Regards,
Khasim

I got overruns when recording audio to a file on the SD card (as in
the examples). I've tried all the different bitrates as well as
mono/stereo, but they all had the same issue. The playback of the
recorded audio file had skips, which I attributed to the overruns
(data that never got stored). The pitch sounded fine, but I was just
hearing fragments (10-20%?) of the audio.

The pico demo played its demo video with audio just fine, so I figured
the playback was working ok and the problem was in audio recording
(especially with the nearly continuous overruns reported).

I had the RevCValidation image on a 2GB pqi SDHC card (I only bought
class 6 cards), which I thought should be fast enough to write content
as slow as audio. I have different sizes in a couple brands to
experiment with. I will re-test with a couple different scenarios
(different card and also on a Debian installation I've been working
on). I may also attempt to just pipe the audio without storing it on
the SD and see if that eliminates that as a factor (assuming
full-duplex audio is possible).

Will let you know how my further tests go...

ok, so I've tested it again a few ways on a different 2 GB card
(RevCValidation image) and on a 8 GB card (diff brand, Debian install)
and I've concluded that there's something going on with the data write
to the SD cards (I've used 2 diff 2 GB cards of the same brand with
the same results).

Validation image, 2 GB pqi SDHC (2 diff cards):
1. overruns when writing to a file in the directory /media/mmcblk0p1
(playback of that file has skips)
2. no overruns when piping arecord directly into aplay (and it sounds
good, too)

Debian install, 8 GB Apacer SDHC:
1. no overruns when writing to a file (root user to its home dir) and
playback sounds good
2. no overruns when piping arecord directly into aplay

On retrospect, I remember having some issues writing to SD cards when
I first started the Debian installation a month ago (I tried both a 4
GB card and an 8 GB card). I would only get part way through the base
installation when I had the installer build the root filesystem on an
ext3 partition. The base install would fail at some random point and
the filesystem was remounted as readonly at that point. On a whim, I
told the installer to build an ext2 partition instead of ext3 and
though I got a few write errors, there were only a few, so the
filesystem never hit the maximum fail count and allowed the
installation to complete successfully.

What things can I look at to troubleshoot access to SD cards? I'm
doing package updates to generate some activity to see if I can get it
to spit out some of the write errors I've seen before, but there must
be some better way to test without burning out the flash memory on the
cards (suppose I could dd from /dev/random or /dev/zero to a good size
file).

Hi…

I’ve done a little more research on what I actually have for SD/SDHC cards. It seems the 2GB cards I have are SD cards with a speed rating of 60x. The 4GB and 8GB cards I have are SDHC cards with a Class 6 rating.

I was able to record audio onto an 8GB SDHC card without overrun errors being reported by arecord, but the 2GB SD card reported overruns.

Can someone else do a little testing to confirm? The 2GB cards I got are the ones recommended on the wiki page: http://code.google.com/p/beagleboard/wiki/BeagleBoardShoppingList

If the Apacer 2GB 60X SD Card listed there has write performance problems for Validation of a BeagleBoard, perhaps it should not be recommended. Alternately, it might be good to find out if this is something with how the BeagleBoard communicates over the SD interface vs the SDHC interface (is the bottleneck the card or a driver?).

I plan on doing some benchmarks with “dd” to see what kind of write speeds are typical for this 2GB SD card and compare that with the SDHC cards I have. The 60x speed rating (technically “up to 60x”) is supposedly faster than the Class 6 cards (“up to 40x”), but unfortunately for the SD card, this specification only applies to reads and not writes (I haven’t found write performance specs for that SD card, yet).

Some good performance data on “sustained reads” and “sustained writes” would be great to have if anyone knows any links to such information for various SD and SDHC cards. This will be the important data needed for streaming audio/video to/from these kinds of devices, as well as many other applications, I’m sure.

-Chris

slight mixup on my part:

  • The card I have is PQI brand, not the Apacer one that is listed on the BeagleBoardShoppingList that I mentioned in my previous mail, but has the same specs otherwise (60x).

Other than that, the whole of my mail is still pertinent. (note: the SHDC cards I have are Apacer brand).

-Chris