Reporting of min and max values of ring buffer size

[aholzinger]

In function static int snd_madifx_playback_open(struct snd_pcm_substream *substream) you set min max constraints for the period size, but for the buffer size you do set only the single constraint:

		snd_pcm_hw_constraint_minmax(runtime,
					     SNDRV_PCM_HW_PARAM_PERIOD_SIZE,
					     32, 4096);
		snd_pcm_hw_constraint_single(runtime,
					     SNDRV_PCM_HW_PARAM_BUFFER_SIZE,
					     8192);

This makes the user mode calls snd_pcm_hw_params_get_period_size_max report 4096, snd_pcm_hw_params_get_period_size_min report 32, snd_pcm_hw_params_get_buffer_size_max report 8192, which is all correct, but it makes snd_pcm_hw_params_get_buffer_size_min also report 8192 which is not correct.

I guess that this would be the better solution:

	snd_pcm_hw_constraint_minmax(runtime,
					     SNDRV_PCM_HW_PARAM_BUFFER_SIZE,
					     64, 8192);

This is not a show stopper, because even if the min buffer size is reported to be 8192, one can still set a smaller one and all works. It's more for coherency sake.

I tried this with the driver, but my observation (using our own software) is that something with the buffer management gets completely screwed up and so I had to revert to the original code. The reporting of the min and max values for the ring buffer size was correct though.

[aholzinger]

I guess I have just learned, that the buffer size is always 8192 and can't be changed :-(

Like this it's also understandable that the driver doesn't work anymore if I replace snd_pcm_hw_constraint_single with snd_pcm_hw_constraint_minmax for SNDRV_PCM_HW_PARAM_BUFFER_SIZE

That unfortunately makes the MADI FX have a lot of latency :-(

[adiknoth]

I guess I have just learned, that the buffer size is always 8192 and can't be changed :-(
[..]
That unfortunately makes the MADI FX have a lot of latency :-(

No, the latency is solely defined by the period size and can be as low as 32 samples. You simply divide the fixed 8192 samples by the desirable period size to get N sub-buffers. On the older RME cards, N was fixed to 2, and the resulting buffer size would vary. Ever since the RayDAT, the buffer size is fixed, and N varies. MADIFX follows the RayDAT approach.

You can try it out with jackd -d alsa --period 64, the console output will show you how many nperiods it has configured.

[aholzinger]

Sorry, I don't get it :-(

When N is not 2, but the period size defines the latency, what are the other period buffers good for?

When N is two, we have the ASIO approach: While the audio app is working on the N=0 period, the hardware is working on the N=1 period and vice versa.

Can you explain what happens with N=4 (buffer size = 8192, period size = 2048)?

[aholzinger]

Are you seated? ;-)

I made the test with an IRIG-B stereo wave file played back on a different computer who sends it via RTP over the nework. The PC with the madifx receives it two times (multicast RTP) and plays it back on an onboard Intel HDA analog device as well as on the madifx (on the phones output). I take only the left channel of both outputs and feed that on a stereo line-in device on the first PC. Now I can measure the offset between left and right channel (left Intel, right madifx).

With identical settings of buffer size 8192, period size 512 for both cards both channels are aligned with an error of about 130 samples.

With the Intel set to buffer size 512, period size 128, the madifx is ca. 8000 samples behind the Intel.

How would you explain that the it's only the period size that defines the latency and not the buffer size?
Why should the madifx be behind the Intel for a value roughly equal to the madifx's buffer size?

[aholzinger]

Any news?