reposting to the list, my email client had some hick-ups.. Paul Davis <paul(a)linuxaudiosystems.com> wrote: OK, but jackd is accessing a DMA buffer - where would that be located for USB devices which doesn't do any real DMA? (OK, maybe that's something for ALSA to figure out) The debugging I was thinking about would be something more fine-grained than just xruns (as I'm not getting any xruns (well, if I choose a period size of 64 I'm getting lots of them). I'm not really sure what to monitor either, just thinking out loud here - it might be interesting to find out where the actual playback and recording pointers are pointing when accessing the buffer to find out whether something is out of sync (it kind of sounds like that, that the beginning of the buffer gets overwritten with new data, or that the end of the buffer somehow isn't completely written when jackd grabs it). Not sure whether jackd can actually see that though (?). The two parts of the buffer (when using two periods) is laid out consecutively in memory, right? One possible explanation might be that jackd gets called a bit to early/late when the audio device/driver is switching buffers, but that would be kind of hard to actually see for jackd as a client to ALSA? (I recognize the audio artifacts from the good old days of DOS demo coding of SoundBlaster DMA, at one point where I had screwed up the logic, writing in the "live" buffer, then the beginning of every period was anything but clean...) This isn't CPU related, there's plenty of CPU time left, and it's occuring all the time, just curious where to start debugging (it seems like it's a jackd problem because aplay works fine, but then again, I guess that aplay doesn't mmap the buffer).. /WernerJ