This thread deals with the Renoise duplex problem http://www.renoise.com/board/index.php?s=b181aa917a954c00bf7498beb7763631&a… This post by modprobe is interesting: "Ok, I know this is kind of an old thread but there are some issues with full duplex that I've been struggling to resolve using ardour jack alsa and an ews88mt soundcard. Here's what I found and why it probably affects other cards / chipsets: "The ews88MT (ice1712 chipset) caused me problems using jackd to do full duplex in ardour, run in capture only I could get latencies of 64 samples, not xruns. Same in Playback only, full duplex I get xruns even with buffer sizes as big as 1024 (after that the driver won't allocate anymore memory for the buffer - xruns get further apart for larger buffers but they always happens eventually). I put some diagnostics in the alsa driver for the card and built a custom jackd. What happens is that the time jackd spends waiting for the capture and record buffers to fill gradually drifts out of sync until one of the buffers (normally the capture one) overruns and an xrun occurs resetting the alsa driver so it can happen again a bit later. But both halves of the card (palyback and capture) run from the same physical clock (so the data sheets say) so how can they drift? What appears to happen is this: "The capture and playback halves of the card count down the number of samples they have DMA'd and then interrupt (to alsa) when the count reaches zero (so you set the count to be the '-p' value in jackd). Alsa then responds to the interrupt, looks at IRQ status to determine what caused it, and processes the audio in or out. The trouble is you can't guarantee that the kernel will respond to an interrupt in less that 20uS (one sample period at 48K). If it does not then the counter will reset and begin counting again before the data has been processed (and the buffer pointers updated) - this means that the capture and playback buffer pointers gradually get out of sync, forcing jackd to wait longer in poll() for both halves of the card to be ready. Eventually one overuns before the other has captured / played enough samples. Therefore, it seems that you cannot guarantee full duplex operation with soundcards that use seperate IRQ/DMA channels for input and output - on playback only or capture only its not a problem as long as the kernel responds in the time taken for one buffer to be played/captured (5ms ish at 256 samples etc) which is normally easilly obtainable. Note: this is a problem for me at the moment on a 2.4GHz athlon X2 so its not just a case of needing a faster PC, you might be ok if your 'lucky' with a kernel that happens to be fast enough but its not a 'hard' parameter. "Why is this not a problem on windows? (it probably is, I could never get rid of crackles and pops with the 88MT and sometimes my recordings seemed as if they were slightly out of time - impossible I though, must be my playing...) I guess it depends on similar factors e..g. what windows 'kernel' you have and what other stuff you have in the system." Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox

On Sat, 3 Jan 2009 03:44:11 -0800 Ken Restivo <ken(a)restivo.org> wrote: Ejem ... http://www.kernel.org/pub/linux/kernel/projects/rt/older/patch-2.6.26.3-rt3… -- Josep Andreu <holborn(a)telefonica.net>