Re: [alsa-devel] For firewire drivers, reduce period time down to 2msec?
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
(Apr 22 2014 05:28), Clemens Ladisch wrote:
Takashi Sakamoto wrote:
Currently I'm working for next patchsets and I'll post them in Friday.
I should be healthy again by then.
I should careflly prepare for these patches, without any bugs which I can realize.
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.
I didn't consider about this case. Yes, exactly. I should remain 4msec or more for period time.
But against your expectation, the examples in my previous message are got with jackd. Today I did easy tests with jackd again but I didn't receive any XRUNs. Of cource, the size of period is nearly 2msec and the number of periods in buffer is 2.
I did also some tests with aplay/arecord. In this case, I can get 'overrun' with arecord and M(mmap) or/and N(nonblock) option, but aplay works fine.
If your expectation and my understanding are correct, all of jackd/aplay/arecord should generate XRUNs. But actually not. Do you have any ideas for these differences?
Thanks
Takashi Sakamoto o-takashi@sakamocchi.jp
(Apr 21 2014 20:38), Takashi Sakamoto wrote:> Hi Clemens,
Currently I'm working for next patchsets and I'll post them in Friday. In this time, I add some patches newly, including your idea to use channel mapping instead of CIP_HI_DUALWIRE for dice driver.
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. So I want to discuss the second one beforehand.
Currently dice/speakers driver apply 5msec for period time. 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. For example:
(snd-bebob) $ cat /proc/asound/GO46/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 6 rate: 32000 (32000/1) period_size: 64 buffer_size: 128
period: 1/32000 * 64 / 1000 = 2.0 msec buffer: 1/32000 * 128 / 1000 = 4.0 msec
$ cat /proc/asound/GO46/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 6 rate: 48000 (48000/1) period_size: 128 buffer_size: 256
period: 1/48000 * 128 * 1000 = 2.7 msec buffer: 1/48000 * 256 * 1000 = 5.4 msec
(snd-oxfw) $ cat /proc/asound/FCA202/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 32000 (32000/1) period_size: 64 buffer_size: 128
period: 1/32000 * 64 / 1000 = 2.0 msec buffer: 1/32000 * 128 / 1000 = 4.0 msec
$ cat /proc/asound/FCA202/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 96000 (96000/1) period_size: 256 buffer_size: 512
period: 1/96000 * 256 * 1000 = 2.7 msec buffer: 1/96000 * 512 * 1000 = 5.4 msec
How do you think about applyting these rules to dice/speakers?
Regards
Takashi Sakamoto o-takashi@sakamocchi.jp
participants (2)
-
Clemens Ladisch -
Takashi Sakamoto