[LAU] Last RT Kernel + Alsa Seq working

[Norval Watson]

This thread deals with the Renoise duplex problem

http://www.renoise.com/board/index.php?s=b181aa917a954c00bf7498beb7763631&showtopic=17849&pid=143801&st=0&#entry143801

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