Takashi Sakamoto wrote:
Currently I'm working for next patchsets and I'll post them in Friday.
I should be healthy again by then.
The patchset also includes my idea to apply common PCM hw constraints to dice/speakers(oxfw)/fireworks/bebob. Currently the constraints includes: 1.Maximum bits for PCM sample is limited by 24. 2.Minimum time for period is currently 2msec. 3.In blocking mode, frames per period/buffer is aligned to SYT_INTERVAL
I think you'll agree with 1 and 3.
Yes.
So I want to discuss the second one beforehand.
Currently dice/speakers driver apply 5msec for period time.
This is just because of the fixed INTERRUPT_INTERVAL, plus lots of safety margin to reduce the relative jitter of the period interrupt. (If the interrupt interval were dynamic, it should be possible to reduce periods to about 0.25 ms.)
I want to reduce this to 2msec. The reason of this '2msec' is:
- Currently firewire-lib process 16 packets in one time.
- This equals to 2msec (= INTERRUPT_INTERVAL / 8000 * 1000)
- During this 2msec, when pcm_period_pointer passes through period
boundary, snd_pcm_period_elapsed() is scheduled with tasklet.
- But tasklet can execute one time even if the function is scheduled
several times before executing it.
- The packetizing process is enough fast so the function can be
scheduled before executing.
- As a result, snd_pcm_period_elapsed() can be called one time every 2msec.
Actually my devices can work fine with period == 2msec or less than 5msec, without any disadvantage.
ALSA actually uses a fixed period _size_. When the period length is set to exactly 2 ms, but the 16 packets between two FireWire interrupts contain one sample less than needed, the ALSA period interupt is delayed until the next FireWire interrupt. In that case, Jack with two periods is likely to underrun.
The minimum time should be increased so that at least one FireWire interrupt is guaranteed to happen for each period, even when there are rounding errors and clock differences.
Regards, Clemens