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=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 E0247C433E0 for ; Tue, 19 Jan 2021 09:06:55 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2D04123135 for ; Tue, 19 Jan 2021 09:06:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D04123135 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id E7B4F1869; Tue, 19 Jan 2021 10:06:01 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz E7B4F1869 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1611047212; bh=BTF1B3Brp192l/gIcLaKG/FHo8+O83gFKZX8nIIaUz0=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=KZb9cfaIwVkrpHT2+upKa0BXWBtr2lHqfjrRkVjDC9K7kcdkT/wxFXG9YDLx2XXDq bGzuJ1cMeIdKcEoP01fh9gFU8A3cJzPSfXu2GQzvi1ap4an6uM33nkj8GztYRJ5dtx I8Mf97mw0ZPKdAngPWAv7pttIjM4A2R4krStOnFQ= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 4D625F80255; Tue, 19 Jan 2021 10:06:01 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id A3A7AF80257; Tue, 19 Jan 2021 10:05:59 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 70DE6F800FE for ; Tue, 19 Jan 2021 10:05:55 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 70DE6F800FE 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 38C8EB905; Tue, 19 Jan 2021 09:05:55 +0000 (UTC) Date: Tue, 19 Jan 2021 10:05:55 +0100 Message-ID: From: Takashi Iwai To: Mike Oliphant Subject: Re: Support for NUX MG-300 USB interface In-Reply-To: References: 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 Cc: alsa-devel@alsa-project.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Tue, 19 Jan 2021 01:26:51 +0100, Mike Oliphant wrote: > > Unfortunately, the "uac_clock_selector_set_val()" call does not seem to > change anything. OK, > >From doing some more testing, I think that the references to clock id "40" > are ok - it has "40" stored in fmt->clock, but when it uses it, > "__uac_clock_find_source()" gets called and it resolved to the actual clock > source - "41". > > Not sure about the "No valid sample rate available for 1:1, assuming a > firmware bug" error, but I suspect it is spurious. > "check_valid_altsetting_v2v3()" is failing for some reason, but it is > ignoring the error. Yes, that's the part where verifying the altsetting for the given rate. The UAC2 device must return the valid altsetting bit mask for the current rate in the request, but your device didn't seem returning it. The code is there for devices like MOTU that have multiple altsets where each one has one sample rate exclusively. > Playback is completely silent, but the system seems to think it is working. > No apparent errors, and a play operation seems to take the correct amount > of time. Just no audio. Check the status in /proc/asound/card*/pcm*/sub*/status. If the pointer moves forward and the position is expected, at least the data feed is done, and the problem must be something else. What about the capture? Do you get also only silence? > Maybe it is a mixer issue? mixer.c is putting out "RANGE setting not yet > supported" errors on startup. That's probably no problem, I guess it comes from the code trying to get the resolution. The patch below may paper over it. > Here is a sample of dmesg output for a playback session: > > [ 4748.260975] usb 1-1.3: Open EP 0x1, iface=1:1, idx=0 > [ 4748.260983] usb 1-1.3: channels=2, rate=48000, format=S32_LE, > period_bytes=48000, periods=4, implicit_fb=0 > [ 4748.260988] usb 1-1.3: Open EP 0x81, iface=1:1, idx=1 > [ 4748.260992] usb 1-1.3: channels=2, rate=48000, format=S32_LE, > period_bytes=48000, periods=4, implicit_fb=0 > [ 4748.260996] usb 1-1.3: Setting usb interface 1:0 for EP 0x1 > [ 4748.261320] usb 1-1.3: 1:1 Set sample rate 48000, clock 40 > [ 4748.261873] usb 1-1.3: Setting params for data EP 0x1, pipe 0x9d00 > [ 4748.261890] usb 1-1.3: Set up 12 URBS, ret=0 > [ 4748.261897] usb 1-1.3: Setting usb interface 1:1 for EP 0x1 > [ 4748.262097] usb 1-1.3: Setting params for sync EP 0x81, pipe 0x9d80 > [ 4748.262105] usb 1-1.3: Set up 4 URBS, ret=0 > [ 4748.262147] usb 1-1.3: Starting data EP 0x1 (running 0) > [ 4748.262180] usb 1-1.3: 12 URBs submitted for EP 0x1 > [ 4748.262183] usb 1-1.3: Starting sync EP 0x81 (running 0) > [ 4748.262193] usb 1-1.3: 4 URBs submitted for EP 0x81 > [ 4748.262311] usb 1-1.3: 1:1 Start Playback PCM > [ 4762.887812] usb 1-1.3: Stopping sync EP 0x81 (running 1) > [ 4762.887836] usb 1-1.3: Stopping data EP 0x1 (running 1) > [ 4762.887849] usb 1-1.3: 1:1 Stop Playback PCM > [ 4762.902542] usb 1-1.3: Closing EP 0x1 (count 1) > [ 4762.902549] usb 1-1.3: Setting usb interface 1:0 for EP 0x1 > [ 4762.902915] usb 1-1.3: EP 0x1 closed > [ 4762.902928] usb 1-1.3: Closing EP 0x81 (count 1) > [ 4762.902935] usb 1-1.3: Setting usb interface 1:0 for EP 0x81 > [ 4762.903179] usb 1-1.3: EP 0x81 closed The flow looks good judging from this log, at least. The device is configured with the dedicated sync endpoint, but it's not with the implicit feedback mode. It's interesting whether the device behaves differently if you load snd-usb-audio module with implicit_fb=1 boot option. I don't expect it working better, but anyway... Takashi --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -1238,7 +1238,7 @@ static int get_min_max_with_quirks(struct usb_mixer_elem_info *cval, (cval->control << 8) | minchn, &cval->res) < 0) { cval->res = 1; - } else { + } else if (cval->head.mixer->protocol == UAC_VERSION_1) { int last_valid_res = cval->res; while (cval->res > 1) {