Larger buffer sizes seemed to have stopped working and small ones are fragile?

Installation & Configuration Linux
#1

I installed Ardour 6 and it seems the maximum buffer size supported for the Alsa backend has gone down? The drop-down menu of Audio/Midi setup has changed in terms of its range?

Moreover, this seems to have caused problems for running the older Ardour 5 variants on the very same machines. I can’t think what has polluted them. Possibly it’s a software automatic upgrade and nothing to do with changing Ardour versions. I’ve tried two machines, and four different USB audio devices (Fedora 31).

My real problem is that I was constantly getting the ‘cannot start audio … possibly hw_params’ dialog pop up, which is not very informative. This is at 44.1 for 16 to 20 channel interfaces. To assist, I recompiled Ardour and passed in the debug=1 flag in the last arg to the constructor of Alsa_pcmi. This then gives more revealing information about why it won’t start, saying on the stdout

Alsa_pcmi: can’t set capture period size to 1024
and
Alsa_pcmi: can’t set capture period size to 512.

when I select those sizes

It does not complain at all for 128 and 256 samples, but it does not start. I will dig further to see why.

For 64 samples, the driver starts ok but bombs out (ALSA I/O error dialog) within the minute or so, correlated with CPU activity on other application programs (I am not using the performance governor for these tests since I want to test my margins). Using the larger buffer sizes would obviously be much more tolerant to inter-process crosstalk, which is why I normally used them (along with hardware foldback and monitoring).

Why do you think the larger buffer sizes are no longer working for me? I’ve not made any system changes as far as I know. I’ll keep on exploring. It’s something to do with the alsa snd_pcm_hw_params_get_period_size

(I must say, it would be helpful to get the informative messages from the backend without having to recompile it. I’ll probably implement a private enabling backdoor from now on (using getenv or something)).

Many thanks - DJ Greaves

#2

What do you think the largest buffer size is now? What do you think it used to be?

#3

Have you select the same device to be used for input and output? What device are you using?

No need to rebuild, just start set an environment variable

ZITA_ALSA_PCMI_DEBUG=15 Ardour6

The reported number of periods will be interesting.
There was a change to increase the number of periods to satisfy a device’s mix/max buffersize (in this case a RME RayDAT).

#4

I’ve always used 1024 samples at 44.1 Ksps with 2 periods and latency build out in both directions of 413 samples on the Focusrite 18i20. The 18i8 had similar figures, but the details are in another building.

I’ve tested an Tascam 16x08 and a CM6206-based unbranded unit.

Yes, same device for input as output.

I found the existing getenv just after I posted earlier.

What do you think the largest buffer size is now? What do you think it used to be?
I’ll have some results in a bit.

I think I’ll dive into the alsa code to see when it decides to deny buffers beyond a certain size.

#5

Many thanks for your attention.

I note that the alsa library has a set_min and set_max calls for parameters. I think these get pushed down into kernel space from an application. Its just possible that Ardour6 sets this parameter and then
Ardour5 is not able to run with its old settings, even if Ardour6 has exited. A reboot should fix that though, and does not seem to, so I’m probably completely wrong to be thinking that Ardour6 is the source of my grief.

Requesting 512 with ZITA_ALSA_PCMI_DEBUG=15 gives
Alsa_pcmi: can’t set playback period size to 512.

It is working on the 18i20 with a buffer size of 256 but not starting with buffers larger than that. The working figures are shown below.

[djg11@musicroom card6]$ cat pcm0c/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 18
rate: 44100 (44100/1)
period_size: 256
buffer_size: 512

[djg11@musicroom card6]$ cat pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 20
rate: 44100 (44100/1)
period_size: 256
buffer_size: 512
[djg11@musicroom card6]$

Earlier I reported it did not work at a setting of 256 or 128 but that problem seems to have gone. I’ve turned off a number of other USB audio devices; perhaps there’s a shared buffer pool and having too many cards plugged in leads to scarcity.

Anyway, the larger buffer sizes used to work.

Many thanks in advance for any insights into what’s changed.

DJ Greaves