Hey, I posted this a few weeks ago, here is the original thread:
http://eca.cx/lad/2004/06/0046.html After doing some research it seems that the issue is actually with JACK. The SBLive does not allow the hardware capture buffer to be set to any values other than these: static unsigned int capture_period_sizes[31] = { 384, 448, 512, 640, 384*2, 448*2, 512*2, 640*2, 384*4, 448*4, 512*4, 640*4, 384*8, 448*8, 512*8, 640*8, 384*16, 448*16, 512*16, 640*16, 384*32, 448*32, 512*32, 640*32, 384*64, 448*64, 512*64, 640*64, 384*128,448*128,512*128 }; This limits the allowed period sizes you can set with snd_pcm_hw_params_set_period_size; this is what jackd uses to set the period size to whatever is specified in the -p argument. However as far as I can tell, you should be able to use the ALSA xfer_align parameter to set this to, say, 128. Then, you set the playback period size to 128, and whenever you get an interrupt from the playback buffer running low you write the next 128 frames to the output device and read the next 128 from the capture buffer. Since the different sized hardware buffers for capture and playback are a quirk of the SBLive, I think this would require hardware-specific code for the EMU10K1 in JACK, the way there is one for the Hammerfall, HDSP, and ICE1712 already. Would someone with more low level knowledge of JACK and ALSA care to comment? Lee
