Thanks for the response. I should have updated this thread when I learned from Alexander Haim that muxing requires privilege. 
Unfortunately interrupt latency would have been too large for my use case, so I used external muxes instead. I posted a write up the beagleboard group. 
I was also pleased to learn other people found my work useful.
Matt Porter referenced my abx project in his presentation at the Embedded Linux Conference.  
boxysean wrote a post about PRU usage that referenced this very thread. 
I think I even see vestiges of the code from this thread in Elias Bakken’s replicape PRU code.  
I love the power of the PRU and I love to see new applications. Sounds like you have something in the works.
I’ve using the PRU with success to read a PCM audio stream from a 3G modem using uio_pru. That way I can leave McASP0 for the audio cape or other codec (since McASP1 isn’t exposed on BB)
My PRU code reads the serial stream and signal with an interrupt when the buffer is half or full (circular buffer) then a thread in userspace code reads the buffer.
The only weird thing I’ve noted that I get exactly two (2) UIO events (the library just block reads /dev/uio) per PRU interrupt. It seems this only happens using UIO.
I use two UIO interrupts one for buffer signaling and the usual end of execution interrupt.
Yes thanks to them. And someone even posted the patch on the official git repo but maintainer hasn’t applied it.
Hi Juanjo, what performance in terms of resolution, latency and sample rate did you push through it? And do you think one could sample one signal with higher precision by somehow sampling the lower part with 12bit and sequentially the upper part with 12bit?