15 Jun
2004
15 Jun
'04
5:19 p.m.
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