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.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 0FEBBC433E0 for ; Sat, 9 Jan 2021 18:18:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C969123A01 for ; Sat, 9 Jan 2021 18:18:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725999AbhAISR6 (ORCPT ); Sat, 9 Jan 2021 13:17:58 -0500 Received: from mx2.suse.de ([195.135.220.15]:43828 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725956AbhAISR6 (ORCPT ); Sat, 9 Jan 2021 13:17:58 -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 7A660AED0; Sat, 9 Jan 2021 18:17:16 +0000 (UTC) Date: Sat, 09 Jan 2021 19:17:16 +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: <20210109194601.f94ca38b2b99ddeb15705993@gmx.com> References: <20210108103513.336e6eb9ad323feff6758e20@gmx.com> <20210109092303.b9a2a2f678a5d1b19b7f27f3@gmx.com> <20210109194601.f94ca38b2b99ddeb15705993@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 18:46:01 +0100, Lauri Kasanen wrote: > > On Sat, 09 Jan 2021 09:16:08 +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. > > No, not yet. But surely an inconsistent buffer size would still play > something, instead of immediately erroring out? In some cases, it's possible. PCM OSS translation has some special way depending on the period ("fragment" in OSS) setup... > > > Only through blind guessing did I stumble upon periods_min. > > > > The periods_min usually defines the hardware/software limit of the > > interrupt transfer. > > Why do you say periods_min=1 makes little sense? At 44.1 khz, that'd be > 172 interrupts per second, which is a lot but workable? There is no hw > limit against 172 irqs/s. Well, it's not about the sample rate or the process speed. You need to know what periods=1 means. periods=1 is a VERY special usage. No double buffering and the driver has to report the precise accurate position without period updates; i.e. it's almost for free-wheeling DMA transfer. Hence periods_min=1 makes sense if the driver may behave like that. > > > - 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? > > No, CONFIG_DYNAMIC_DEBUG, CONFIG_DEBUG_FS and CONFIG_SND_DEBUG are all > disabled because this is a memory-constrained platform. Surely "why my > app is not producing sound" is not something that needs several > different kernel debug options enabled (+ root perms b/c debugfs). But you are debugging the *kernel* problem, not the application. I agree that debugfs isn't always needed for hunting application bugs, yeah. Takashi