7 Jun
2004
7 Jun
'04
8:19 p.m.
I kind of answered my own question, this seems to be hardcoded into the
ALSA driver. See this post:
http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg12718.html
Here is the code form emupcm.c:
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
};
static snd_pcm_hw_constraint_list_t hw_constraints_capture_period_sizes = {
.count = 31,
.list = capture_period_sizes,
.mask = 0
};
From looking at the driver sources and reading
Takashi's ALSA driver guide, these
are supposed to represent the physical
constraints of the underlying hardware. I am
currently experimenting with changing these to something closer to what we
know the hardware is capable of, starting with the period sizes the kX driver offers
(64, 128, 256, 512). I don't see why this wouldn't work, as we know from the
kX drivers that the above do not represent the actual physical hardware constraints.
Unfortunately the kX people can only offer moral support ;-), as they have signed
NDA's
with Creative to get hardware documentation. This is how their driver supports
96khz/24bit and the rest of the newer Audigy features.
Lee
On Mon, 2004-06-07 at 17:43, Robert Jonsson wrote:
måndagen den 7 juni 2004 23.02 skrev Lee Revell:
Hey,
It seems to be a known issue that you cannot run JACK with the capture
period size lower than 512 with the SBLive ALSA driver. See this
thread:
http://ccrma-mail.stanford.edu/pipermail/planetccrma/2003-December/003764.h
tml
and this:
http://www.music.columbia.edu/pipermail/linux-audio-user/2003-April/004040.
html
The above threads seem to indicate that this is a hardware limitation.
However it seems to me more like a driver issue. Using the kX drivers
(on Windows, http://www.kxproject.com) with the exact same card, an old
SBLive Platinum, Ableton Live is usable with the record and playback
period sizes (set via ASIO driver config) at 64 samples (2.33 ms
latency) with nothing else running, and rock solid at 128 (~5 ms) in the
face of basically anything you throw at it. Of course it crashes, as
it's Windows, using an alpha quality third-party driver, but is quite
usable in a live music setting. 512x2 is not really usable for my
purposes.
Is this assessment correct, and if so, can someone familiar with the
SBLive ALSA driver give me an idea as to how this could be fixed? Could
this be done via ALSA config files maybe?
Your assessment is probably correct, I've brought up this issue a few times
before. Fact is the ALSA driver for emu10k1 does not allow to set the capture
buffer smaller than 512. Exactly why is still unknown, atleast to me.
Unfortunately I don't think it can be solved with configuration.
Talking to the kx people would probably be a good idea if you wish to dive
deeper into this issue. The ALSA lists is another place to try.
Regards,
Robert
>
> Lee