From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA924C433E6 for ; Sat, 9 Jan 2021 08:17:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8717B23A1C for ; Sat, 9 Jan 2021 08:17:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726210AbhAIIQu (ORCPT ); Sat, 9 Jan 2021 03:16:50 -0500 Received: from mx2.suse.de ([195.135.220.15]:46932 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726321AbhAIIQu (ORCPT ); Sat, 9 Jan 2021 03:16:50 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DD2F5AB7A; Sat, 9 Jan 2021 08:16:08 +0000 (UTC) Date: Sat, 09 Jan 2021 09:16:08 +0100 Message-ID: From: Takashi Iwai To: Lauri Kasanen Cc: linux-mips@vger.kernel.org, tsbogend@alpha.franken.de, perex@perex.cz Subject: Re: [PATCH 5/6 v2] sound: Add n64 driver In-Reply-To: <20210109092303.b9a2a2f678a5d1b19b7f27f3@gmx.com> References: <20210108103513.336e6eb9ad323feff6758e20@gmx.com> <20210109092303.b9a2a2f678a5d1b19b7f27f3@gmx.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Sat, 09 Jan 2021 08:23:03 +0100, Lauri Kasanen wrote: > > Hi, > > On Fri, 08 Jan 2021 10:06:48 +0100 > Takashi Iwai 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. 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