On 14/04/10 12:32 AM, Mark Lord wrote: ..
The syslog shows the usual "fallback" messages, but the audio consisted of very loud static, the kind of noise one gets when the sample bits are all reversed. While it was failing, I tried retuning, stopping/starting the recording, etc.. nothing mattered. It wanted a reload of the cx18 driver to cure it.
.. Since all of this happens rather randomly, I'm beginning to more strongly suspect a race condition somewhere in the driver. Now, it's a rather large driver -- lots of complexity in that chip -- so it will take me a while to sort through things. But at first blush, I don't see any obvious locking around the various read-modify-write sequences for the audio registers. And a quick "grep spin *.[ch]" shows a few spin_lock/spin_unlock calls in cx18-queue.c and cx18-stream.c (as well as the alsa code, which shouldn't be in play in this scenario). Oddly, none of those spinlocks use _irq or _irq_save/restore, which means they aren't providing any sort of mutual exclusion against the interrupt handler. But like I said, I'm only just beginning to look more closely now. -- Mark Lord Real-Time Remedies Inc. mlord@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
