View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0008075ardourbugspublic2020-05-02 16:492020-07-01 16:49
Reportermpk Assigned Tox42  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version6.0-pre1 
Summary0008075: Capture and playback periods don't match (ALSA)
DescriptionAfter selecting Periods=3 in Audio/MIDI Setup I noticed in STDOUT that this is only applied to the playback, not to capture. Should this not apply to both playback and capture streams?
Steps To Reproduce1. Start a new session with ALSA backend
2. Select Periods: 3
3. Note message in STDOUT

playback :
  nchan : 18
  fsamp : 44100
  fsize : 512
  nfrag : 3
  format : S32_LE
capture :
  nchan : 18
  fsamp : 44100
  fsize : 512
  nfrag : 2
  format : S32_LE
synced
Additional InformationIt can be verified that the resultant buffer sizes are different:

$ cat /proc/asound/card1/pcm0c/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 18
rate: 44100 (44100/1)
period_size: 512
buffer_size: 1024
$ cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 18
rate: 44100 (44100/1)
period_size: 512
buffer_size: 1536
TagsNo tags attached.

Activities

x42

2020-05-02 17:20

administrator   ~0024036

Capture latency is always exactly 1 cycle.

mpk

2020-05-03 13:33

reporter   ~0024048

OK. Jack seems to match capture and playback latency, but fine as long as this is intentional.

agus.terol

2020-05-04 12:45

reporter   ~0024059

x42, if capture latency is always exactly 1 cycle, why is it configured to 2 cycles? Or cycles != periods? As you might have alreday noticed, I am interested in the latency compensation ;)

So, if you can elaborate a bit more, I would be very grateful. Thank you!

x42

2020-05-10 20:27

administrator   ~0024120

This is a peculiar design of ALSA. I/O to the device still happens at the configured buffersize, the difference is that you can use additional buffering which, in case of output, does allow an application to be late.

The minimum number pf periods is two.

time     +---------->
Input    :   ABCDEF
Process  :   .ABCDE                                                                                                                                                                            
Out. n=2 :   ..ABCD
Out. n=3 :   ...ABC


Even more confusing is that you can configure a large number, but keep the read-pointer near the start (which is why there's only one period of capture latency), or move the write-pointer near the end of the buffer to minimize I/O latency, regardless of the configured number of periods.

Anyway I've just changed Ardour to use the same number of periods for in and out. I suppose that's safer for some drivers. The overall latency however does no change

x42

2020-05-10 20:29

administrator   ~0024121

Fixed in 6.0-rc1-238-g4ff6fbe6b8

anonymous

2020-07-01 16:49

viewer   ~0024553

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2020-05-02 16:49 mpk New Issue
2020-05-02 17:20 x42 Note Added: 0024036
2020-05-03 13:33 mpk Note Added: 0024048
2020-05-04 12:45 agus.terol Note Added: 0024059
2020-05-10 20:27 x42 Note Added: 0024120
2020-05-10 20:29 x42 Assigned To => x42
2020-05-10 20:29 x42 Status new => resolved
2020-05-10 20:29 x42 Resolution open => fixed
2020-05-10 20:29 x42 Note Added: 0024121
2020-07-01 16:49 anonymous Note Added: 0024553
2020-07-01 16:49 anonymous Status resolved => closed