Hi,
On Fri, 08 Jan 2021 10:06:48 +0100
Takashi Iwai <tiwai@xxxxxxx> wrote:
> > +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.
Only through blind guessing did I stumble upon periods_min.
- why did it break OSS apps?
- how does the OSS layer interact with periods? I didn't find any "set
period" ioctl
- 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
- Lauri
