On Sat, 09 Jan 2021 08:23:03 +0100,
Lauri Kasanen wrote:

Hi,

On Fri, 08 Jan 2021 10:06:48 +0100
Takashi Iwai [off-list ref] wrote:

quoted

quoted

+static const struct snd_pcm_hardware n64audio_pcm_hw = {
+	.info = (SNDRV_PCM_INFO_MMAP |
+		 SNDRV_PCM_INFO_MMAP_VALID |
+		 SNDRV_PCM_INFO_INTERLEAVED |
+		 SNDRV_PCM_INFO_BLOCK_TRANSFER),
+	.formats =          SNDRV_PCM_FMTBIT_S16_BE,
+	.rates =            SNDRV_PCM_RATE_8000_48000,
+	.rate_min =         8000,
+	.rate_max =         48000,
+	.channels_min =     2,
+	.channels_max =     2,
+	.buffer_bytes_max = 32768,
+	.period_bytes_min = 1024,
+	.period_bytes_max = 32768,
+	.periods_min =      1,

periods_min=1 makes little sense for this driver.

I have some questions about this.

When I had periods_min = 128, OSS apps were broken. I mean simple ones,
open /dev/dsp, ioctl the format/rate/stereo, write data. They got an IO
error errno IIRC, and no clarifying error in dmesg.

I tried following the error with printks, several levels deep. I gave
up when it got to the constraint resolving function, and there was no
good way to print and track which constraint failed, why, and who set
the constraint.

Did you try to set up the hw constraint for the integer PERIODS like
below at open?
  snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS)

Without this, it'd allow inconsistent buffer/period set up in your
case.

Only through blind guessing did I stumble upon periods_min.

The periods_min usually defines the hardware/software limit of the
interrupt transfer.

- why did it break OSS apps?
- how does the OSS layer interact with periods? I didn't find any "set
period" ioctl

OSS layers do the same as the native API via OSS emulation in
sound/core/oss/pcm*.c.

- why was there no clarifying error in dmesg? Just an errno that means
a million things makes it impossible for the userspace app writer to
know why it's not working

Did you check the debug messages with dyndbg enabled?


Takashi