Markus,

Did you ever figure this problem out? We are using a gumstix for a closely related situation to yours. (GPIO PTT). 

Does the 12-hour handle reset always fix your problem?

Sincerely,
Blaine Booher
Clifton Labs, Inc
(513)-400-5606 (work)
(937)-570-9336 (cell)



On Sat, Feb 11, 2012 at 12:29 PM, Markus Svilans <msvilans@aeonyx.ca> wrote:
Dear gumstix-users,

Recently, I have become aware of an interesting problem with audio
acquisition on the Gumstix.

The application is a voice communication device, partly implemented
using a Gumstix Overo and its on-board audio hardware.

The program constantly captures mono audio at 8kHz. It transmits the
digital audio to a modem, whenever the user holds down a push-to-talk
(PTT) button. The PTT button is connected to the Gumstix using a GPIO.

During some long test runs recently, we found that the audio acquisition
hangs for no apparent reason. It always hangs after the same length of
time after the program is started.

Debugging revealed that it always hangs at a call to ALSA function
snd_pcm_readi(). There is no error or any outward sign of a problem...
the audio capture thread just permanently blocks on the call to
snd_pcm_readi(). The problem goes away when the program is killed and
restarted. The call to snd_pcm_readi() invariably hangs after exactly
2097151360 samples have been acquired. This translates to 72.8 hours
after audio capture was started.

The best workaround we have at the moment is to shut down the ALSA
capture handle, and re-open it, every 12 hours. It works, because so far
the time-to-hang is a reliable 72.8 hours after the ALSA capture handle
is started.

Perhaps coincidentally, the time-to-hang is suspiciously close to a
signed 32-bit sample counter overflowing....

    (2^31 samples) / (8000 samples per second) / (3600 seconds per
hour) = 74.6 hours


Software versions:
Linux kernel 2.6.34
ASLA 1.0.23

Hardware:
Gumstix Overo Air


The ALSA capture handle is opened in blocking mode. Another ALSA
playback handle is used in non-blocking mode.

The workaround is a bit of a hack... it appears to work, but it's
somewhat unnerving to need to do that, in a communication product that
is supposed to run for reliably for many weeks, without interruption.

Has anyone ever witnessed something similar?
Does anyone have a suggested solution?


Thanks &  best regards,
Markus



------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users