From nobody Sun Dec 10 15:38:45 2023 X-Original-To: multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sp8DQ0ZT4z540sK for ; Sun, 10 Dec 2023 15:38:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sp8DP5b8Vz3LqQ for ; Sun, 10 Dec 2023 15:38:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702222725; a=rsa-sha256; cv=none; b=TaFhjK2JR0XlCzBDRN37rlD3RAq751ZRGfsN4bRRmr4yDnLBLQsYEkzynnmBpY6zvNImLn ouTKxCCYVGAd6Zig8NWvOtMDtd0sjhG3I9GcQhStBczLa+JOSIbFM3WjFFdgHSz2mbIvN4 sFFJnJc+iMesKwSwrTqk9XS8I1JhuLYR8ND84ks4/BqpPSGhSp+9h9fvLdUJyeRyuFh8Et mFaTUZeIiAiUhDzzSRQCvA5m1GVLVZdLRb2DfAqNVE5swSxfGPzeJQP85ZESj1mwfEh7D4 Z2A5QQYLKDTyVbIFbjCFQm30+pIRvLRhtDAS7cga1E2ovF4MsoGljtRNf+5ERQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702222725; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NnvMr2LLK4EpT5QBI7fng3UI77TZ7rpNLMuDDUnJC2U=; b=YAMJs2jwBzjngiVVTPC3/s44OnB2O0RkEPeogxgD/BloAxA6YSlXW++9raxTlqbcNdo9Ew 6YVwbU3TG82YGNNuMOUDUAR+13lU4zTL5eSxNR7b8zRiiuTKcBtsBwn6tiwY+8DpStuzq5 GO2Tl8AstPx4mdE8t/GMKsK1gGAVUSD6pMF3JKbSL3kGl3A6A+By89n2oCqZHj4owy1QT5 mGQGCbL8p5o8ffAKMbnV7ft+OHrWrYC1YuPNS15xyc/9EWK0TadwlKZxZJLq6ZgDeMgNRY GgFGT8eUq65IghxlrcpxjaDm+4BQoFuxuOdSr6EvD8q7Oy4UlpGxZdWIHR0ogw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Sp8DP4dzLzshJ for ; Sun, 10 Dec 2023 15:38:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3BAFcjnH070664 for ; Sun, 10 Dec 2023 15:38:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3BAFcjMk070663 for multimedia@FreeBSD.org; Sun, 10 Dec 2023 15:38:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 275615] multimedia/ffmpeg: compilation failure in libavcodec/librsvgdec.c Date: Sun, 10 Dec 2023 15:38:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: philippe.michel7@free.fr X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275615 --- Comment #1 from Philippe Michel --- The issue is not FreeBSD-specific and has been reported upstream as https://trac.ffmpeg.org/ticket/10722 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Dec 11 12:09:19 2023 X-Original-To: multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SpgXH5CBKz53WPh for ; Mon, 11 Dec 2023 12:09:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SpgXH4Bcnz3MXl for ; Mon, 11 Dec 2023 12:09:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702296559; a=rsa-sha256; cv=none; b=lJ8RF0m29tFUSLGgt+6O85XdRLeuRC2EIMeesK8t6X+MxQtS23jKr1LRrzuk8OkEKbO8cS 0ea0LWxPhD6prSirFCZKJW+edq8nQfiVZKiw2I5YuQgdEKM/fr03eR26BRRtJr1kdYbyOw DZ/dXGr/nacza9gaeiN+9W5a0XYmfkYkFLDDiUQSHAb9Hio4CJHI/qffygqGyI1Z+cAGad ErClRn2CYB7MRHGU/euLo99ESffuYJpvT6theFDpPCtvz0PVfzeG7RsqkSrjiBYZOX0lEE /dRDcQ0FdaBZa+jYLtM9Zjh/RqjFgXRBb1ZGSnlU79TJz6mjsrwwXRRcIKL0+Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702296559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g2Y5ZQC0UkpT9XDFf5r7B3f5yk2d0P+79xvyZUfuACQ=; b=Tqy5icD8OQi5E8s1SigjkgY0AsPfP5hBIwQ0H9gWpaDmACmxovICmmrzn8+CzMKvhghAyw iOgK0Km+S1ROGOCxoCh0Q7UeETWRqnZ/Ch56C3nFyjf1PfUT38TKUOfQQt5VLnBhE9ewye fzHYhKKYNAWBFvI4J2VQEgPHwfwpuCfhMGaAg3pTPdkugEg4mWBY67dNSpss/xLlwPRjov gx5to4ltplSZZ3ok8vACX8kSnVYvch7k15vuOMjApXcTy9MZR3dAjbo6qsz7N2ljSdt1Rc dIsCWtnLoiBW5Z0vrAQ5PFdHn6tXD32rx0BYAE0q4E3GgQMsk/DzKTW+l5DEUQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SpgXH3GGfzVkg for ; Mon, 11 Dec 2023 12:09:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3BBC9JYM002234 for ; Mon, 11 Dec 2023 12:09:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3BBC9JX3002233 for multimedia@FreeBSD.org; Mon, 11 Dec 2023 12:09:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 267218] audio/gstreamer1-plugins-chromaprint sys/v4l2codecs/meson.build:38:2: ERROR: Unknown variable "gstcodecs_dep" Date: Mon, 11 Dec 2023 12:09:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: shwetamalikdelhi@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267218 Shweta Malik changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shwetamalikdelhi@gmail.com --- Comment #10 from Shweta Malik --- There have been always https://www.shwetamalik.in/hauz-khas-call-girls.html common queries that avail in front of us. Which is that can we make a cash payment when the call girl will reach our place? And some people like you a= re always confused about that how a Call Girl Hauz Khas will work to provide escort services. We always made possible things for customers that they nev= er pay the call girl personally. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Dec 12 14:58:33 2023 X-Original-To: multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SqMF52ZRmz54418 for ; Tue, 12 Dec 2023 14:58:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SqMF50tXMz4RJC for ; Tue, 12 Dec 2023 14:58:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702393113; a=rsa-sha256; cv=none; b=xWdsWssrZlf60X1X65ABpOewPOc9aPWnCHQMtHsLHqVqn4PC/1sWdwK6zcdI2uP2B+sA2J oTKy0eNb7aozAnfZCiXwDSef0c8ipFoNH9z2eMM3DL66zczW55tJtHmTc6KQbrQMXHzsLN s4XCInjvByFnGsiIrwhnUVEBBWRn2p3TyDyE/X4f8OupM4s92JPZzDhdd+lxcWtWpfxga8 nj4/djzNIYn++PNGNDsw1lirivB9ajN4FJ4PF5ZSqMeqvQOYS/w7RPLvFFyV6tCHy2iqJh ofT8KJR8MxeNrXHrOEUsROwBymSFWi7c0WNYZlHd+44BvX8aH3h1GlAsiRlekg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702393113; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xI32MG28K5mWUni6oE9GfvWWKwQJT9dn8oltmq+T+Go=; b=slRV4hmjWrMWmT3T4hs9WNXr6sx0WE5jCnJGJ8boe6Nc8C6g/VgicG5IR+6i/Mb0f5COwI 8J4rOGNG+jE93ARop6+kRseO9LAGthS7fH8wLbK8QNU1UpSQERuWpZZ5NsNZsyZfh9yXyB eYvCc1C5XSfrdgN7UZ93YkyJHJsrcjlG7Q9/OobH2bnwG3z3v8ifGwx86hUQLWF+ZSfiyG nRLDUh+QUF1+wswHKiCWJLKuXOSoqla/adVkCnJrI9TtvblV+IoqnJ4Tq0iYetFmAVs/3q IKGWVd+/1PWnSC8AU/X1jaGRYWABCANYtsLe4KPdzNW/6sTzConRphsDRCMj2w== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SqMF475WFz4gX for ; Tue, 12 Dec 2023 14:58:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3BCEwWjq077559 for ; Tue, 12 Dec 2023 14:58:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3BCEwWaM077558 for multimedia@FreeBSD.org; Tue, 12 Dec 2023 14:58:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 275057] audio/libsndfile: CVE-2022-33065 fix not available in quarterly branch Date: Tue, 12 Dec 2023 14:58:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: geofflassner@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275057 --- Comment #1 from geofflassner@gmail.com --- Also looking for this to be updated to 1.2.2_1 Thank you. Cheers, Geoff --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Dec 13 15:45:30 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sr0Ds5x08z53wWQ for ; Wed, 13 Dec 2023 15:45:33 +0000 (UTC) (envelope-from jrm@freebsdfoundation.org) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sr0Ds0pLgz3Z6m for ; Wed, 13 Dec 2023 15:45:33 +0000 (UTC) (envelope-from jrm@freebsdfoundation.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=freebsdfoundation.org header.s=gfnp-20170908 header.b=ECGtDbsb; spf=pass (mx1.freebsd.org: domain of jrm@freebsdfoundation.org designates 2607:f8b0:4864:20::836 as permitted sender) smtp.mailfrom=jrm@freebsdfoundation.org; dmarc=none Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-425cbee636fso24141841cf.0 for ; Wed, 13 Dec 2023 07:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsdfoundation.org; s=gfnp-20170908; t=1702482332; x=1703087132; darn=freebsd.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=vG1T6RDGBsXPDq1FhrQVHtkuTiERj4EDdromuRCVzwg=; b=ECGtDbsbSG2lp8GRaQGb8N4LxHpFOp96AbR9AboPkMRyx7ZvpBlpAlCU0wMPWlV+iO FsAK4Epk0stw5K3E6eWJ8o0pWl+yYv6ZXKi/MpnvzFo1Opi3z9HU9g6Me2D8ceQT4wtW 8xDylduKEBzcPzxX7B5C+ouRg6ej5a9C2HDEacxIEuIEFAYPM/HXDtQlXt5v5PnYBzO/ wQnoC5Al/JCflfyTZ5nETMmckbaW6YnUe5LW9DST/AnGzRP9jYpQezOxvmCXZsulHBL/ N17ftSZfcfK4ir76AzyRAXKdzVPHyO/A8Ox/jgQDf0UpZxDk5eOROKV3uIIlqthsJDI5 +Sjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702482332; x=1703087132; h=content-transfer-encoding:mime-version:user-agent:message-id:date :subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vG1T6RDGBsXPDq1FhrQVHtkuTiERj4EDdromuRCVzwg=; b=MIDKIAiiJBs1/KNDrMtxUEptmIBzlx0ZRJiR8RYjDGszIqQq1bTmgAalPRVOPHYBOp 0A5VFZms9bLyKeuyktDSF21cYLIBwgxzrSBxEZGt1Z8OpFTQI5GJuqnmi/tZ7CGRX8sH uYhO5kfkMa9tCfVRx9lkMsbs+xYCruUCq3/B+G39GsWSvFBei+pM69JsmrHG7vS7jmrX LfoIYB4qjvKWdty4ELavqIPUiozvVDX5XgOvWKLOnCC7tVLdyJbwfw1v5Fu+hqeev+cm 0BGvw+XLJkUimX9GJBtUak1mCnSOVOJjZhhlHzZVXD9kYRBhHgj3o0jjYCfrllLNY3EK M+5w== X-Gm-Message-State: AOJu0Yzy+xwdF7/RSj3peuHf0zRhIHZwmo6c/KDpk82Oh4XhcI6LTlIo IvrRdh/upSBq1C0jqh7vZReZE5eOmm5wqVr7b+g9qrAsnoq/oGcsEErb9/bR5n8azy6x8pwaRAr trRjUMd7on/m9qDTy9IIMWkhAaXSEFI4tyw6YFcbnslyBACnsQeAKoUyOft0W6UxyjI6VElFoBd ajVkSCC5rnFQVEOnp/SsGl3eo= X-Google-Smtp-Source: AGHT+IGssh+4csDlMc7A+6K81xxafOpW6hhy7EyLhMMaFr1EM/ZvXQWKqhQ1/imZpj7pX0bOErK4Xw== X-Received: by 2002:a05:622a:151:b0:425:4043:41bb with SMTP id v17-20020a05622a015100b00425404341bbmr12229665qtw.103.1702482331852; Wed, 13 Dec 2023 07:45:31 -0800 (PST) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-174-56.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.174.56]) by smtp.gmail.com with ESMTPSA id h26-20020ac8549a000000b004254304015csm4974827qtq.85.2023.12.13.07.45.31 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 13 Dec 2023 07:45:31 -0800 (PST) From: Joseph Mingrone To: freebsd-multimedia@freebsd.org Subject: RFC - Work on FreeBSD's Audio Stack Date: Wed, 13 Dec 2023 11:45:30 -0400 Message-ID: <86ttomxg11.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[freebsdfoundation.org:s=gfnp-20170908]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::836:from]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org]; DKIM_TRACE(0.00)[freebsdfoundation.org:+]; DMARC_NA(0.00)[freebsdfoundation.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[jrm]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-multimedia@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Sr0Ds0pLgz3Z6m X-Spamd-Bar: --- Hello, The FreeBSD Foundation will be contracting out work on FreeBSD's audio stac= k. If you have any comments about the work, please share them before next = Wednesday, December 20? Joe =3D=3D=3D * Executive Summary The FreeBSD audio stack is one of those fields that does not attract the sa= me attention and development as others do, since it has been left largely unmaintained, and, although high in quality,= there is still room for improvement - from lack of audio development frameworks, to missing userland utilities and kernel d= river-related bugs. This project is meant to touch on all those areas, and as such, will be more of a general improvemen= t project, than an implementation of a specific feature. * Project Description The end goal of the project is to provide FreeBSD audio developers with use= ful tools and frameworks to make sound development on FreeBSD easier, without having to resort to custom solutions= for everything. On the user side, FreeBSD will ship with a more stable audio stack and a la= rger collection of userland programs, making for a more coherent ecosystem in general. OSS generally does not come with = many native tools except mixer(8), and users have to resort to using tools from multiple different audio systems (ALSA, = PulseAudio, sndio) to compensate. Additionally, I think the introduction of new development frameworks will encourage more = native audio development, which is going to be especially beneficial for people - me included - who want to use FreeBSD= for music production. * Deliverables Note: By nature of the project, it is possible that the exact details of so= me deliverables may change. The deliverable list mentioned in the proposal is likely to grow if time constraints allow, so c= onsider it a non-exhaustive list. snd hda(4) pin-patching Regarding the stability of the audio stack, the project will address the pi= n-patching issue present in the snd hda(4) (Intel High Definition Audio) driver. Essentially, some laptop models have non-sta= ndardized mappings for the headphone and speaker jack pins, which results in absence of audio from the headphones, u= ntil a patch is manually applied in snd hda(4) to correctly map the headphone and speaker pins for that model so that the = same audio stream is output from both the speakers and headphones when they are plugged in. The initial strategy to address the issue will be to see if it is possible = to do the patching automatically by figuring out what the Speaker pin=E2=80=99s as number is (see dev.hdac.=C2=A1n=C2=BF.pin= dump=3D1) and =E2=80=9Cforcibly=E2=80=9D assign the same value to the headp= hone jack pin as well. The following solutions follow the same logic: =E2=80=A2 https://bugs.freebsd.org/bugzilla/show bug.cgi?id=3D273809 =E2=80=A2 https://i-bsd.com/freebsd-wireless-8265/ OpenBSD=E2=80=99s azalia(4) (their version of the HDA driver) will also ser= ve as a point of reference, even though it too contains a kind of manual patching mechanism. snd uaudio(4) fixes The project will also address bugs in the USB audio driver, snd uaudio(4), = which I have been able to reproduce using my Focusrite Scarlett USB sound card, with the most prominent and consistent o= ne being noise produced during the first 12 seconds of playback and when moving along a track/video. If the user tries = to move forward multiple times in a short time window, the audio device most of the time becomes unusable (i.e no audio) a= nd it has to be replugged. Though this issue is largely bypassed if audio is routed to the USB device through virtual os= s, this is still a bug that needs to be addressed. Related bug reports include: =E2=80=A2 https://bugs.freebsd.org/bugzilla/show bug.cgi?id=3D257082 =E2=80=A2 https://bugs.freebsd.org/bugzilla/show bug.cgi?id=3D194527 Initially I am going to test whether the open() and read() routines cause t= his issue, as DTrace suggests that this happens around the same time open(2) or the first read(2) is called. As mentioned i= n the previous paragraph, virtual oss partially fixes this issue, so I would like to investigate and understand why, and ma= ybe find the root cause that way. Another source of information will be Linux=E2=80=99s Scarlett and USB audio driver= s which, as far as I know, do not have this issue. Other USB audio bugs include 1) those mentioned in the snd uaudio(4) man pa= ge, 2) snd uaudio(4) not passing enough information (e.g device name, associated device in /dev, and more) to the O= SS API, 3) no explicit list of supported sound cards. MIDI device cloning Unlike DSP devices, sound(4) does not allow cloning of MIDI devices, meanin= g applications cannot open the same MIDI device multiple times (e.g when recording more than one track with the same= device). This can be verified by tracing the dsp clone() routine found in sys/dev/sound/pcm/dsp.c, which is triggere= d during a dev clone EVENTHANDLER(9) event. For example, given a /dev/dsp8.0 device, trying to cat(1) /dev/dsp8.= 1 would trigger dsp clone() and create it on the fly (see FILES section in sound(4) man page). However, doing that with = a MIDI device would trigger the handler, but result in an error, as MIDI devices do not support cloning. To fix this= , the MIDI code will be patched to use the snd clone framework used for cloning DSP devices. Other kernel improvements Other improvements to the kernel code include 1) better-syncing with the 4F= ront OSSv4 API, 2) addressing open bug reports, 3) making optimizations where possible. oss(3) Following the motivation behind mixer(3), which was to make OSS mixer devel= opment more pleasant and easier, I will implement an oss(3) library, responsible for handling the audio device=E2= =80=99s state. oss(3) will serve as a unified interface for OSS audio and MIDI developers and allow for quicker application development, li= ke Digital Audio Workstations, instrument effects, audio servers, and general utilities. Widely-used existing codebases that can benefit from oss(3) are virtual oss= and Mozilla=E2=80=99s cubeb oss audio framework, which are also great sources of inspiration for features included in oss(3). audio(8) FreeBSD lacks an easy-to-use audio device handling utility similar to mixer= (8), but for the device-side of OSS, like OpenBSD=E2=80=99s audioctl(8). Such a utility will make use of the new oss(= 3) library, and offer a cleaner and user-friendlier interface, concentrating all useful - but scattered - information currently= provided by /dev/sndstat, hw.snd, dev.pcm and hw.usb.uaudio, the OSS API into the output of a single application. Hot-swapping Users of plain OSS, that is, without virtual oss, will have noticed that ho= t-swapping audio devices (i.e changing the default unit, hw.snd.default unit) mid-track does not work and sound keeps coming o= ut of the previous device until the track is restarted. This is because applications open(2) the device at the start = of playback and close(2) it when the track has stopped. virtual oss(8) can create a virtual audio device responsible for r= outing audio to the appropriate physical audio device. The device(s) sound is routed to can be changed at run-time using v= irtual oss cmd(8). This method has the advantage that sound can be re-routed to different devi= ces while applications keep the same /dev/dsp open; virtual oss(8) will make any necessary conversions on the fly and red= irect audio to the new device without requiring a restart of the track/application. This functionality will be embedded in either mixer(8) or the new audio(8) = program. Bluetooth device management utility Although not strictly audio-related, I plan to write a (possibly using bsdd= ialog) bluetooth device management utility. Setting up bluetooth devices on FreeBSD is still rather complicated and con= fusing, and involves setting up multiple different programs to even pair with a bluetooth device. This tool will det= ect nearby bluetooth devices, prompt the user to choose which one(s) they want to (un-)pair with, and handle configuratio= n automatically. Other userland improvements Smaller improvements include 1) revisiting some parts of mixer(3) and mixer= (8) with backwards compatibility in mind, 2) writing a MIDI testing utility similar to sndio=E2=80=99s midicat(1) and= ALSA=E2=80=99s aseqdump(1). * Development Process Development will be done on a local Git branch of main, which will also be = available on GitHub. Patches will be submitted for review on FreeBSD=E2=80=99s Phabricator and eventually committed to ups= tream by me once reviewed and accepted. Testing Testing will be done on both VMs and actual hardware, with each patch build= -tested locally and on the FreeBSD cluster. The project will require testing some of the kernel patches with multiple d= ifferent audio devices. Additionally, there will be new tests written for the FreeBSD test suite, for both the kernel and us= erland parts. The audio driver will be tested by writing a test program to go through mos= t of the IOCTLs provided to by the driver, to both confirm that the information returned is correct, and also to make = sure that users cannot pass values that would break the driver. Exact cases will be considered further down the project. For the userland parts, I will write scripts similar to the old mixer(8)=E2= =80=99s test script. Documentation The documentation part of the project includes updating the Wiki, Handbook = and Foundation pages to reflect the most recent changes and additions. New Handbook sections will be added to showca= se the use of oss(3) and mixer(3). with additional examples added to /usr/share/examples/sound. Man pages with miss= ing, incomplete or outdated information will be addressed. From nobody Thu Dec 14 02:59:13 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SrHBG41Xlz52k3N for ; Thu, 14 Dec 2023 02:59:18 +0000 (UTC) (envelope-from jrm@freebsdfoundation.org) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SrHBD6JR6z4Txk for ; Thu, 14 Dec 2023 02:59:16 +0000 (UTC) (envelope-from jrm@freebsdfoundation.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=freebsdfoundation.org header.s=gfnp-20170908 header.b=DeDEp2B3; spf=pass (mx1.freebsd.org: domain of jrm@freebsdfoundation.org designates 2607:f8b0:4864:20::f35 as permitted sender) smtp.mailfrom=jrm@freebsdfoundation.org; dmarc=none Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-67f02843e91so4558196d6.0 for ; Wed, 13 Dec 2023 18:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsdfoundation.org; s=gfnp-20170908; t=1702522755; x=1703127555; darn=freebsd.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:from:to:cc:subject:date :message-id:reply-to; bh=aTvYPaaZbBm78m4WxdcBQDZojuoLqhlxWJa00ACU/hw=; b=DeDEp2B3tR4yyNnIdP5nPI/kvw0YjVfBvFz+Lorx+aHu50MEh4oXr94ReDqQN3vZYK RuGFRMvBzaBOCG5Ww43AolkQrMuoecJgO9jHzq4pLKqOzOKcTa4tSAgQ46XLK3iOQfqa qZ7UodSX/OK2rUlpoFD5j9ksmVYLjZz/DtPpCLoVnxfLyXtAAYRIHxr1+RyYGrzeCs/y AOp+x0HZxLjCQRRVe07CDkQqf3vOcUrSO/MB8upKciaXsiwkUUXgcJJcBw3crQCeC+V2 N7IY1WWJ21oNVkqTC9ouw/Pd4ovW8nyvxOJhjGahI8zcZJJh7NbgzGUxtwuXITFqf1hK Ng3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702522755; x=1703127555; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=aTvYPaaZbBm78m4WxdcBQDZojuoLqhlxWJa00ACU/hw=; b=btknXpVlItmpoCz1ZpsWFFanon52D1YyqfYqdjT6pT9BZv9p34dos7VqrPGjYY+y5X 0jcYXQU+ttgvszN44WQV9XPnH+RQrjf/Qgzxy8XFSAtzJxbK9SXvu80jtnInTV83igwB lP7SXaXp9UYD8jN1QRJlBL0WuuRjGv34Jrd7CDcpzZUZhC+c4acftoSnJ8hpFWhHVYL0 iW4Yg2nFRQw7/i0bApLkWcet9XU3zcdMdMSyf807BySxr34myChiD6LPWIdsLYwmQtVW j8C6QBeFOasCGKpnhZpZ+ZNU+bmEfh90j6lkTvp0MDaN4w0ZMQA01/5qPPgwxRrKsGuz JzRg== X-Gm-Message-State: AOJu0YzqgCY/K7vGXoeBnMenvJayzG/SY4JTr57JiP3G+HkVe88BqCIs qP56SY0OQVjzdCd97h2qObCMBLw/MfgpFyE8kznrq8v4+nFXcmszg+wOGtV5zqWoCpwafueVUVu 3hmgck0JMcgSwN6svXmjldl5U00W3uTk95suR7y5A2fBmSTb53PCSbEstcqUK1BdMwpEkIGS4aL l6adc5y4EMWOL1z4ik2DVM+Jc= X-Google-Smtp-Source: AGHT+IH3/gSrWFKXxv6Luzn49a0h1I7aqFWEvFgduvSgjSr96ARGcPtLWRhckpb6LKM8A4hCxXHv5w== X-Received: by 2002:ad4:40c5:0:b0:67f:21a:d4eb with SMTP id x5-20020ad440c5000000b0067f021ad4ebmr1420161qvp.43.1702522754952; Wed, 13 Dec 2023 18:59:14 -0800 (PST) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-174-56.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.174.56]) by smtp.gmail.com with ESMTPSA id ml1-20020a056214584100b0067f04aa5fe0sm453644qvb.14.2023.12.13.18.59.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 13 Dec 2023 18:59:14 -0800 (PST) From: Joseph Mingrone To: freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack In-Reply-To: <86ttomxg11.fsf@phe.ftfl.ca> (Joseph Mingrone's message of "Wed, 13 Dec 2023 11:45:30 -0400") References: <86ttomxg11.fsf@phe.ftfl.ca> Date: Wed, 13 Dec 2023 22:59:13 -0400 Message-ID: <86y1dxpjzy.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[freebsdfoundation.org:s=gfnp-20170908]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f35:from]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org]; DKIM_TRACE(0.00)[freebsdfoundation.org:+]; DMARC_NA(0.00)[freebsdfoundation.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[jrm]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-multimedia@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SrHBD6JR6z4Txk X-Spamd-Bar: --- Re-sending the text because the original contained a few errors, the worst = being broken URLs from a PDF to text conversion. Hello, The FreeBSD Foundation will be contracting out work on FreeBSD's audio stac= k. If you have any comments about the work, please share them before next = Wednesday, December 20. Joe =3D=3D=3D * Executive Summary The FreeBSD audio stack is one of those fields that does not attract the sa= me attention and development as others do, since it has been left largely unmaintained, and, although high in quality,= there is still room for improvement - from lack of audio development frameworks, to missing userland utilities and kernel d= river-related bugs. This project is meant to touch on all those areas, and as such, will be more of a general improvemen= t project, than an implementation of a specific feature. * Project Description The end goal of the project is to provide FreeBSD audio developers with use= ful tools and frameworks to make sound development on FreeBSD easier, without having to resort to custom solutions= for everything. On the user side, FreeBSD will ship with a more stable audio stack and a la= rger collection of userland programs, making for a more coherent ecosystem in general. OSS generally does not come with = many native tools except mixer(8), and users have to resort to using tools from multiple different audio systems (ALSA, = PulseAudio, sndio) to compensate. Additionally, I think the introduction of new development frameworks will encourage more = native audio development, which is going to be especially beneficial for people - me included - who want to use FreeBSD= for music production. * Deliverables Note: By nature of the project, it is possible that the exact details of so= me deliverables may change. The deliverable list mentioned in the proposal is likely to grow if time constraints allow, so c= onsider it a non-exhaustive list. snd hda(4) pin-patching Regarding the stability of the audio stack, the project will address the pi= n-patching issue present in the snd hda(4) (Intel High Definition Audio) driver. Essentially, some laptop models have non-sta= ndardized mappings for the headphone and speaker jack pins, which results in absence of audio from the headphones, u= ntil a patch is manually applied in snd hda(4) to correctly map the headphone and speaker pins for that model so that the = same audio stream is output from both the speakers and headphones when they are plugged in. The initial strategy to address the issue will be to see if it is possible = to do the patching automatically by figuring out what the Speaker pin=E2=80=99s as number is (see dev.hdac..pindump=3D1) = and "forcibly" assign the same value to the headphone jack pin as well. The following solutions follow the same logic: - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273809 - https://i-bsd.com/freebsd-wireless-8265/ OpenBSD=E2=80=99s azalia(4) (their version of the HDA driver) will also ser= ve as a point of reference, even though it too contains a kind of manual patching mechanism. snd uaudio(4) fixes The project will also address bugs in the USB audio driver, snd uaudio(4), = which I have been able to reproduce using my Focusrite Scarlett USB sound card, with the most prominent and consistent o= ne being noise produced during the first 12 seconds of playback and when moving along a track/video. If the user tries = to move forward multiple times in a short time window, the audio device most of the time becomes unusable (i.e no audio) a= nd it has to be replugged. Though this issue is largely bypassed if audio is routed to the USB device through virtual os= s, this is still a bug that needs to be addressed. Related bug reports include: - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257082 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194527 Initially I am going to test whether the open() and read() routines cause t= his issue, as DTrace suggests that this happens around the same time open(2) or the first read(2) is called. As mentioned i= n the previous paragraph, virtual oss partially fixes this issue, so I would like to investigate and understand why, and ma= ybe find the root cause that way. Another source of information will be Linux=E2=80=99s Scarlett and USB audio driver= s which, as far as I know, do not have this issue. Other USB audio bugs include 1) those mentioned in the snd uaudio(4) man pa= ge, 2) snd uaudio(4) not passing enough information (e.g device name, associated device in /dev, and more) to the O= SS API, 3) no explicit list of supported sound cards. MIDI device cloning Unlike DSP devices, sound(4) does not allow cloning of MIDI devices, meanin= g applications cannot open the same MIDI device multiple times (e.g when recording more than one track with the same= device). This can be verified by tracing the dsp clone() routine found in sys/dev/sound/pcm/dsp.c, which is triggere= d during a dev clone EVENTHANDLER(9) event. For example, given a /dev/dsp8.0 device, trying to cat(1) /dev/dsp8.= 1 would trigger dsp clone() and create it on the fly (see FILES section in sound(4) man page). However, doing that with = a MIDI device would trigger the handler, but result in an error, as MIDI devices do not support cloning. To fix this= , the MIDI code will be patched to use the snd clone framework used for cloning DSP devices. Other kernel improvements Other improvements to the kernel code include 1) better-syncing with the 4F= ront OSSv4 API, 2) addressing open bug reports, 3) making optimizations where possible. oss(3) Following the motivation behind mixer(3), which was to make OSS mixer devel= opment more pleasant and easier, I will implement an oss(3) library, responsible for handling the audio device=E2= =80=99s state. oss(3) will serve as a unified interface for OSS audio and MIDI developers and allow for quicker application development, li= ke Digital Audio Workstations, instrument effects, audio servers, and general utilities. Widely-used existing codebases that can benefit from oss(3) are virtual oss= and Mozilla=E2=80=99s cubeb oss audio framework, which are also great sources of inspiration for features included in oss(3). audio(8) FreeBSD lacks an easy-to-use audio device handling utility similar to mixer= (8), but for the device-side of OSS, like OpenBSD=E2=80=99s audioctl(8). Such a utility will make use of the new oss(= 3) library, and offer a cleaner and user-friendlier interface, concentrating all useful - but scattered - information currently= provided by /dev/sndstat, hw.snd, dev.pcm and hw.usb.uaudio, the OSS API into the output of a single application. Hot-swapping Users of plain OSS, that is, without virtual oss, will have noticed that ho= t-swapping audio devices (i.e changing the default unit, hw.snd.default unit) mid-track does not work and sound keeps coming o= ut of the previous device until the track is restarted. This is because applications open(2) the device at the start = of playback and close(2) it when the track has stopped. virtual oss(8) can create a virtual audio device responsible for r= outing audio to the appropriate physical audio device. The device(s) sound is routed to can be changed at run-time using v= irtual oss cmd(8). This method has the advantage that sound can be re-routed to different devi= ces while applications keep the same /dev/dsp open; virtual oss(8) will make any necessary conversions on the fly and red= irect audio to the new device without requiring a restart of the track/application. This functionality will be embedded in either mixer(8) or the new audio(8) = program. Bluetooth device management utility Although not strictly audio-related, I plan to write a (possibly using bsdd= ialog) bluetooth device management utility. Setting up bluetooth devices on FreeBSD is still rather complicated and con= fusing, and involves setting up multiple different programs to even pair with a bluetooth device. This tool will det= ect nearby bluetooth devices, prompt the user to choose which one(s) they want to (un-)pair with, and handle configuratio= n automatically. Other userland improvements Smaller improvements include 1) revisiting some parts of mixer(3) and mixer= (8) with backwards compatibility in mind, 2) writing a MIDI testing utility similar to sndio=E2=80=99s midicat(1) and= ALSA=E2=80=99s aseqdump(1). * Development Process Development will be done on a local Git branch of main, which will also be = available on GitHub. Patches will be submitted for review on FreeBSD=E2=80=99s Phabricator and eventually committed to ups= tream by me once reviewed and accepted. Testing Testing will be done on both VMs and actual hardware, with each patch build= -tested locally and on the FreeBSD cluster. The project will require testing some of the kernel patches with multiple d= ifferent audio devices. Additionally, there will be new tests written for the FreeBSD test suite, for both the kernel and us= erland parts. The audio driver will be tested by writing a test program to go through mos= t of the IOCTLs provided to by the driver, to both confirm that the information returned is correct, and also to make = sure that users cannot pass values that would break the driver. Exact cases will be considered further down the project. For the userland parts, I will write scripts similar to the old mixer(8)=E2= =80=99s test script. Documentation The documentation part of the project includes updating the Wiki, Handbook = and Foundation pages to reflect the most recent changes and additions. New Handbook sections will be added to showca= se the use of oss(3) and mixer(3). with additional examples added to /usr/share/examples/sound. Man pages with miss= ing, incomplete or outdated information will be addressed. From nobody Thu Dec 14 04:10:51 2023 X-Original-To: multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SrJmr26mcz52pDP for ; Thu, 14 Dec 2023 04:10:52 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SrJmq5Y7rz4Z68 for ; Thu, 14 Dec 2023 04:10:51 +0000 (UTC) (envelope-from portscout@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702527051; a=rsa-sha256; cv=none; b=bZ7/n4W+/Uxei2vh8i/zX/x0bEhCxwfh+EQKrm2G+FRaaURYtoe+6rIu1rN9MJqG5OtsFJ yCwqRRN/pb08Rmz4CbZndxzAOEC81lC15klcwoDRRj8bWqcqL9xQroMWefD3Dtc8Q1S0Si zrxgoDzOl5bM0Rmxi2yTzQFTeoEUnX1vipcFlj/RCXDWYsZkvpl+uCxrTYNFiX7RVYsCox NAUuwrpJkACnQQTiEVzO7L6R0QdNTSoHSZMR3GH0VyeGmBdJiNwj9emrVWZJLObTOJLR0p rv/E8iZvo2SXVuJBDr/68aPCNLO5zr8yfGR28DoG0d39plOaCFFFKAexu/tLug== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702527051; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=lUg42yZ6YnDykyMHwXXiWOvfG3Wc41lrGosSB46lT9A=; b=PUEjSGTnyEz5O0BQ2NJwudD1cnF3LQh4AvTs0n0rOJsJylMEoQDUcE2fXVvRMQAvFGQEjR yAsQCJl87YaEHqNYDbdeVj1+iiHWLbYKZys/LVzziPgF3NxRQNU7nnsEdzOep1Io/QBv9+ plaVVcy0qr9INlpGdqxuW9MRY+jMjSdeJAxLDK6MNgMGCReHoZgUnDVM6YR2b1LeA6StNC pQ6CrLxqvliZAWVYGxL2tHV4G4J+xXj5J4+xPPnSj+Yi3JAJ+Y+c9Fa/4rXeBFTa7SuUrA 9B+Lrk30qtvJvp91QC8PBNokVSYDsWEz4qgDJTfIFkIJlIa6Ya0zBY5JRmQF0Q== Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SrJmq4YVWz1R39 for ; Thu, 14 Dec 2023 04:10:51 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.17.1/8.17.1) with ESMTP id 3BE4Apqq034326 for ; Thu, 14 Dec 2023 04:10:51 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.17.1/8.17.1/Submit) id 3BE4ApDh034325; Thu, 14 Dec 2023 04:10:51 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202312140410.3BE4ApDh034325@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 Date: Thu, 14 Dec 2023 04:10:51 +0000 From: portscout@FreeBSD.org To: multimedia@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/multimedia@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ textproc/libebml | 1.4.4 | 1.4.5 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Thu Dec 14 13:02:10 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SrXZX3F0Fz53xcq for ; Thu, 14 Dec 2023 13:02:44 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SrXZW737cz4fPB for ; Thu, 14 Dec 2023 13:02:43 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1702558951; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bT9VbhZw/XOni77wRoKk5s9OSltpuJBGUZ5/zBtjzk4=; b=PeLgYXl/+bmK/G1cDtoS+jbdhYbNkdPKergOMCcfZ5HSNPLeUhHIkk2HAs+hUPCb4PfNhw rxe8FiZ9yFKat9R7uRPoSNrykU7DdCP8zghUjVK36L0PCHLdv+gmBeAUtvn01GBK+GjbQS xRcS1nniFOX0kfjFG9dByf8PF9jLOCQfyvtWmLk7envXJ190Vbolq23/Tn/roouL7raLdf 3b1QaBijglAt5rJjByyIvD1sfSONUgngKavh12dzFfyr89bIssw0GhxpGMWRKi2uCVFvDj sF9bYZPEwtWNeV3W4a6hb092yKmGxEwkOp3OZB1kJOYok+cjmF+wKoBAXNzNew== Date: Thu, 14 Dec 2023 14:02:10 +0100 From: Alexander Leidinger To: Joseph Mingrone Cc: freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack In-Reply-To: <86y1dxpjzy.fsf@phe.ftfl.ca> References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca> Message-ID: <5240adad4ff5b341756809fe12d362c9@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_c9b39592d0503b7ed7a265757daa3a73"; micalg=pgp-sha256 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SrXZW737cz4fPB This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_c9b39592d0503b7ed7a265757daa3a73 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2023-12-14 03:59, schrieb Joseph Mingrone: > * Deliverables > > Note: By nature of the project, it is possible that the exact details > of some deliverables may change. The deliverable list > mentioned in the proposal is likely to grow if time constraints allow, > so consider it a non-exhaustive list. If you want to integrate some drivers: https://lists.freebsd.org/pipermail/freebsd-multimedia/2019-June/019719.html https://lists.freebsd.org/pipermail/freebsd-multimedia/2019-September/019907.html No idea if they are good quality drivers or not, and if those cards are still available, but at least someone tried to support them it may be sensible to check if it makes sense to do something with them or not. > snd hda(4) pin-patching Great. > snd uaudio(4) fixes > Other USB audio bugs include 1) those mentioned in the snd uaudio(4) > man page, 2) snd uaudio(4) not passing enough > information (e.g device name, associated device in /dev, and more) to > the OSS API, 3) no explicit list of supported sound > cards. Regarding 2) we may want to think about increasing the default verbosity of /dev/sndstat... > MIDI device cloning > > Unlike DSP devices, sound(4) does not allow cloning of MIDI devices, > meaning applications cannot open the same MIDI > device multiple times (e.g when recording more than one track with the > same device). This can be verified by tracing > the dsp clone() routine found in sys/dev/sound/pcm/dsp.c, which is > triggered during a dev clone EVENTHANDLER(9) > event. For example, given a /dev/dsp8.0 device, trying to cat(1) > /dev/dsp8.1 would trigger dsp clone() and create it on > the fly (see FILES section in sound(4) man page). However, doing that > with a MIDI device would trigger the handler, > but result in an error, as MIDI devices do not support cloning. To fix > this, the MIDI code will be patched to use the > snd clone framework used for cloning DSP devices. The dsp deices are clonable due to the virtualisation and auto-mixing into the hardware in the kernel. To my understanding the midi devices are not clonable as there is no generic way we could mix several outputs from programs into one hardware channel. > Other kernel improvements > > Other improvements to the kernel code include 1) better-syncing with > the 4Front OSSv4 API, 2) addressing open bug > reports, 3) making optimizations where possible. 1) I mentored a student in the Google summer of code which resulted in what we have now in the OSSv4 API. Parts of this work was done as stubs, e.g. #ifdef OSSV4_EXPERIMENT static int dsp_oss_getlabel(struct pcm_channel *wrch, struct pcm_channel *rdch, oss_label_t *label); static int dsp_oss_setlabel(struct pcm_channel *wrch, struct pcm_channel *rdch, oss_label_t *label); static int dsp_oss_getsong(struct pcm_channel *wrch, struct pcm_channel *rdch, oss_longname_t *song); static int dsp_oss_setsong(struct pcm_channel *wrch, struct pcm_channel *rdch, oss_longname_t *song); static int dsp_oss_setname(struct pcm_channel *wrch, struct pcm_channel *rdch, oss_longname_t *name); #endif and also dsp_oss_setchnorder(). Maybe you are interested to un-stub them. > oss(3) > > Following the motivation behind mixer(3), which was to make OSS mixer > development more pleasant and easier, I will > implement an oss(3) library, responsible for handling the audio > device’s state. oss(3) will serve as a unified interface for OSS > audio and MIDI developers and allow for quicker application > development, like Digital Audio Workstations, instrument > effects, audio servers, and general utilities. > > Widely-used existing codebases that can benefit from oss(3) are virtual > oss and Mozilla’s cubeb oss audio framework, > which are also great sources of inspiration for features included in > oss(3). VirtualOSS is now unmaintained (the author died). Maybe we want to adopt it into the base? > audio(8) > > FreeBSD lacks an easy-to-use audio device handling utility similar to > mixer(8), but for the device-side of OSS, like > OpenBSD’s audioctl(8). Such a utility will make use of the new oss(3) > library, and offer a cleaner and user-friendlier > interface, concentrating all useful - but scattered - information > currently provided by /dev/sndstat, hw.snd, dev.pcm and > hw.usb.uaudio, the OSS API into the output of a single application. The kernel code also contains some XXX comments with some userland ideas, e.g. for the buffersize. > Hot-swapping > > Users of plain OSS, that is, without virtual oss, will have noticed > that hot-swapping audio devices (i.e changing the default > unit, hw.snd.default unit) mid-track does not work and sound keeps > coming out of the previous device until the track > is restarted. This is because applications open(2) the device at the > start of playback and close(2) it when the track has > stopped. virtual oss(8) can create a virtual audio device responsible > for routing audio to the appropriate physical audio > device. The device(s) sound is routed to can be changed at run-time > using virtual oss cmd(8). > > This method has the advantage that sound can be re-routed to different > devices while applications keep the same /dev/dsp > open; virtual oss(8) will make any necessary conversions on the fly and > redirect audio to the new device without requiring > a restart of the track/application. > > This functionality will be embedded in either mixer(8) or the new > audio(8) program. > > Bluetooth device management utility > > Although not strictly audio-related, I plan to write a (possibly using > bsddialog) bluetooth device management utility. > Setting up bluetooth devices on FreeBSD is still rather complicated and > confusing, and involves setting up multiple > > different programs to even pair with a bluetooth device. This tool will > detect nearby bluetooth devices, prompt the user > to choose which one(s) they want to (un-)pair with, and handle > configuration automatically. Someone started with a bluetooth daemon a while ago. It sounds like this and your proposal share a common goal. No idea what the state of it is, but maybe you want to check it out: https://lists.freebsd.org/archives/freebsd-bluetooth/2022-August/000021.html > Documentation > > The documentation part of the project includes updating the Wiki, > Handbook and Foundation pages to reflect the most > recent changes and additions. New Handbook sections will be added to > showcase the use of oss(3) and mixer(3). with > additional examples added to /usr/share/examples/sound. Man pages with > missing, incomplete or outdated information > will be addressed. Some parts of the kernel sound code contain docs written in doxygen syntax. A rendered version of it (if there is no error in the daily generation for -current) is available at https://www.leidinger.net/FreeBSD/dox/dev_sound/html/ and the corresponding TODO markup is rendered at https://www.leidinger.net/FreeBSD/dox/dev_sound/html/dd/da0/todo.html an example of the function docs (for dsp_oss_syncgroup()) is at https://www.leidinger.net/FreeBSD/dox/dev_sound/html/d5/d3b/dsp_8c.html#a304ece74c26d57a7df3ab5f104a3feff It would be nice if changes to the kernel maintain/add to the doxygen markup. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_c9b39592d0503b7ed7a265757daa3a73 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmV6/OMACgkQEg2wmwP4 2IaX/Q/+L+5wmGy7gP0I3RvEnoBWayDLtrlmGaHCcaU/KOhrA5BRjm95D9q88ghw M+4r4svkab08BlWjnCPuyNI7lk04ueuwOygexkecTaQnboNQUbfC+EbHPAyi+2Tv 0WbIQRjHcGGXgxGtMqONRzZM/WsPL2q0KbTyhsI9pbRGGrnIyTqgLFMRWw3FLsxj CJZIjuGx25oH9HQkB+Le8tW2+/nGRSN24qmbJ0GQjSnuxY0Be8kyZlQYY+yW2c5J 4NzercpjKhkXbi+oGFCUYKN7og5mPd2XAGicgXZsYvids0bdqbMQOMJx38vNkLom bEVkMPZqqpSgmaRwRCUsAeF2x1NNIcTIx2OCH9G1njzZFFmwsk2UBMVZxRPzhZf+ a5DHkt6TOQyEPRpGG8VIpzNWry5fkhI6Kva3p6H5g99SmRSnayQXsWFarwUFrvqq IKgzBnZmdu53lm9UOWj/yKEh3Mk8bFpBTKDcdO7utZo8Scyd5jHK11OzpzzUTomW oUzVkF7vy70uZOMJnlQvEzRreNzRb1fwCo3QZGSRmH5tbYkHk3stOdUdrNaMjQK8 o8YwPF6seNQsLsdBpEVuTD/luEQvZmxVk7CotloQmsKzR9rge9ENoie4BplVYM2R J2RC95t14h5G8vKM+c8oX2MgQIcPe6xKk9wCS0MZo9Yy+1IX13E= =DTjx -----END PGP SIGNATURE----- --=_c9b39592d0503b7ed7a265757daa3a73-- From nobody Thu Dec 14 13:51:06 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SrYfN6rzlz54107 for ; Thu, 14 Dec 2023 13:51:08 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SrYfN6QcBz3DP4; Thu, 14 Dec 2023 13:51:08 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702561868; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FfWG/XidAMDT469TWFS3g2Hk95KgO26O5QOXTtEL+/U=; b=bCVJ2S26bezFd8gYyF6WbCve143R38FOAnOdtVd9FQoFOPTJKAnT5vMlSN1tMRkrmauQnb lqgViMT+n08kiuD05fOQufDDuWdQjoX6ki35vzRSMCm9CwbH/LypC8pVOeYOgfN0QwiMci 95nqdFBfh6vwobNldNTNM9jcBrv9MXfSbzuVMgDIKfOIbEb9OsWi9z8UEIyEz1V6swbSdK VwaQ0wbinzo0VCKwQWJAmFyRxCL23IvIu7oqGGzUy4qXwJWCsAQ+LzxU22qtaLf/Nzd2iK SnSJoOJD3ZYFl8HbRHEaYjxhcoLS5sNykeh3gk0PXH3x63BmL9ssxoMqGg1SzQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702561868; a=rsa-sha256; cv=none; b=RUuvujQXxZdIilwI88WSma/VEE3XuJdUlPB9h939wVFDoeDe5X3XXhnIzBjQuKEey7mx/6 P1PBZ+VO2eMnQpXpi1Gi1t7l8xdJUHDvjNTP7DhClWf3ZWdJJJgB5vqs7tIGsbmk1Nzg1w NxbB9C4teg/tnEZAbBTcMhJ07LNgEbhHaQ0RvDU6zSS+SHstifCb6AXZGepDItpsk5xxhL C1G7LnGUFQGWWUxzBSqACN9smijIkMkJ1OKL/HPWujt79Fer3EhNZjbRdEjmQ5dwR67l50 6nYxzubD/pKzPuMedeIpmwElVeOhNbgRG3RrUceORSQp4w4RUeO2VAN4Mz30gA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702561868; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FfWG/XidAMDT469TWFS3g2Hk95KgO26O5QOXTtEL+/U=; b=X2+W3AypOEJYQyAsq9/4tDFT+TXjAcHBUrffttPkymPHHEEI5bZ8I+lm42BrqhkMyqLoTV IwBTqD/fVpvNsh6vLRfheOjO9SNwET2XUILYZ9Z0ZEr4QUrEcVJrnVh4jJ072jVVHhKcM+ pFsaQ/QOkX8bgXQuo+Rk7J0j7XAE9FtCptL9//TU674yHJCqMMf9GeHfxrEi+4v6ewyrd6 sU5dUsDT7zwQwNnTg8w/RtbgdsOcmvQWQOuro7bzNDhtli0G4l8GzR5dPudvpJJFRrS232 JyDukr4U3mIZdxB/fCGiBJ313L7aTibs6216JLtLnA/+U+/8CydEhWaeneb9/g== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SrYfN4N6RzkCr; Thu, 14 Dec 2023 13:51:08 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id EEDC515CBBD; Thu, 14 Dec 2023 14:51:06 +0100 (CET) Date: Thu, 14 Dec 2023 14:51:06 +0100 From: Baptiste Daroussin To: Joseph Mingrone Cc: freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack Message-ID: <5gncptsagv7vr6omipmttdel73uq3dx3gvjz3nsvsleqlmqdmu@denmsyow3yzj> References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca> List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86y1dxpjzy.fsf@phe.ftfl.ca> On Wed, Dec 13, 2023 at 10:59:13PM -0400, Joseph Mingrone wrote: > Re-sending the text because the original contained a few errors, the worst being broken URLs from a PDF to text conversion. > > Hello, > > The FreeBSD Foundation will be contracting out work on FreeBSD's audio stack. If you have any comments about the work, please share them before next Wednesday, December 20. > > Joe > > === > > * Executive Summary > > The FreeBSD audio stack is one of those fields that does not attract the same attention and development as others do, > since it has been left largely unmaintained, and, although high in quality, there is still room for improvement - from lack > of audio development frameworks, to missing userland utilities and kernel driver-related bugs. This project is meant to > touch on all those areas, and as such, will be more of a general improvement project, than an implementation of a specific > feature. > > * Project Description > > The end goal of the project is to provide FreeBSD audio developers with useful tools and frameworks to make sound > development on FreeBSD easier, without having to resort to custom solutions for everything. > > On the user side, FreeBSD will ship with a more stable audio stack and a larger collection of userland programs, making > for a more coherent ecosystem in general. OSS generally does not come with many native tools except mixer(8), and users > have to resort to using tools from multiple different audio systems (ALSA, PulseAudio, sndio) to compensate. Additionally, > I think the introduction of new development frameworks will encourage more native audio development, which is going to > be especially beneficial for people - me included - who want to use FreeBSD for music production. > > * Deliverables > > Note: By nature of the project, it is possible that the exact details of some deliverables may change. The deliverable list > mentioned in the proposal is likely to grow if time constraints allow, so consider it a non-exhaustive list. > > snd hda(4) pin-patching > > Regarding the stability of the audio stack, the project will address the pin-patching issue present in the snd hda(4) (Intel > High Definition Audio) driver. Essentially, some laptop models have non-standardized mappings for the headphone and > speaker jack pins, which results in absence of audio from the headphones, until a patch is manually applied in snd hda(4) > to correctly map the headphone and speaker pins for that model so that the same audio stream is output from both the > speakers and headphones when they are plugged in. > > The initial strategy to address the issue will be to see if it is possible to do the patching automatically by figuring out > what the Speaker pin’s as number is (see dev.hdac..pindump=1) and "forcibly" assign the same value to the headphone > jack pin as well. The following solutions follow the same logic: > > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273809 > - https://i-bsd.com/freebsd-wireless-8265/ > > OpenBSD’s azalia(4) (their version of the HDA driver) will also serve as a point of reference, even though it too contains > a kind of manual patching mechanism. > > snd uaudio(4) fixes > > The project will also address bugs in the USB audio driver, snd uaudio(4), which I have been able to reproduce using my > Focusrite Scarlett USB sound card, with the most prominent and consistent one being noise produced during the first 12 > seconds of playback and when moving along a track/video. If the user tries to move forward multiple times in a short time > window, the audio device most of the time becomes unusable (i.e no audio) and it has to be replugged. Though this issue > is largely bypassed if audio is routed to the USB device through virtual oss, this is still a bug that needs to be addressed. > > Related bug reports include: > > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257082 > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194527 > > Initially I am going to test whether the open() and read() routines cause this issue, as DTrace suggests that this happens > around the same time open(2) or the first read(2) is called. As mentioned in the previous paragraph, virtual oss partially > fixes this issue, so I would like to investigate and understand why, and maybe find the root cause that way. Another > source of information will be Linux’s Scarlett and USB audio drivers which, as far as I know, do not have this issue. > > Other USB audio bugs include 1) those mentioned in the snd uaudio(4) man page, 2) snd uaudio(4) not passing enough > information (e.g device name, associated device in /dev, and more) to the OSS API, 3) no explicit list of supported sound > cards. Another issue which is painful with uaudio, more and more laptops have uaudio devices by default instead of hda, and uaudio is not able to suspend/resume if something is consuming it. This is the only hotpluggable device we have for snd card, when one is going to suspend, the device is being detached not suspended (because usb) and the decatch procedure goes through the pcm_unregister function which loops forever hoping the application using the device will die, which never happens, so suspend ends up in an infinite loop in the kernel. Note the same happen if you disconnect any uaudio device while an application is using it. Best regards, Bapt From nobody Thu Dec 14 23:34:39 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Srpbm1tDtz53wvK for ; Thu, 14 Dec 2023 23:34:44 +0000 (UTC) (envelope-from christos@freebsd.org) Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Srpbl5C9Cz3NYH for ; Thu, 14 Dec 2023 23:34:43 +0000 (UTC) (envelope-from christos@freebsd.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=mail; bh=nPwyNCh7vs/2re0 oZwrIIbITW/6ddCdcFafmnpSX4Xs=; h=in-reply-to:references:subject:cc:to: from:date; d=margiolis.net; b=XMcLpTKeJblTbMqI4ySoveILLA4smBHnAt82fKGo wP3dimFfHsIbhhrZSnX37/EJ2UCcDQzfSNSXsx7ZH44YH+vknZp5uTc0vnC2dlK9a4ghbJ +YPSjwxr33M5tMs9iaHsL29bNQiEfTBTempLcicjzficcVZ3GF80iMzwx0iXo= Received: from pleb (ppp-94-66-59-140.home.otenet.gr [94.66.59.140]) by margiolis.net (OpenSMTPD) with ESMTPSA id 79318638 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Thu, 14 Dec 2023 23:34:40 +0000 (UTC) Date: Fri, 15 Dec 2023 01:34:39 +0200 From: Christos Margiolis To: Alexander Leidinger Cc: freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack Message-ID: References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca> <5240adad4ff5b341756809fe12d362c9@Leidinger.net> List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5240adad4ff5b341756809fe12d362c9@Leidinger.net> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:95.179.144.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Srpbl5C9Cz3NYH Hello Alexander, Alexander Leidinger wrote: > If you want to integrate some drivers: > https://lists.freebsd.org/pipermail/freebsd-multimedia/2019-June/019719.html > https://lists.freebsd.org/pipermail/freebsd-multimedia/2019-September/019907.html > > No idea if they are good quality drivers or not, and if those cards are > still available, but at least someone tried to support them it may be > sensible to check if it makes sense to do something with them or not. Because of time constraints, I really don't think this would be a wise allocation of time, so for now I am not going to look into this, I can note it down on a future TODO list however, if there's interest from more people. > The dsp deices are clonable due to the virtualisation and auto-mixing into > the hardware in the kernel. To my understanding the midi devices are not > clonable as there is no generic way we could mix several outputs from > programs into one hardware channel. Is there any other way we can achieve the functionality mentioned in the proposal though (i.e opening the same MIDI device from more than 1 application at the same time)? > > Other improvements to the kernel code include 1) better-syncing with the > > 4Front OSSv4 API, 2) addressing open bug > > reports, 3) making optimizations where possible. > > 1) I mentored a student in the Google summer of code which resulted in what > we have now in the OSSv4 API. Parts of this work was done as stubs, e.g. > #ifdef OSSV4_EXPERIMENT > static int dsp_oss_getlabel(struct pcm_channel *wrch, struct pcm_channel > *rdch, oss_label_t *label); > static int dsp_oss_setlabel(struct pcm_channel *wrch, struct pcm_channel > *rdch, oss_label_t *label); > static int dsp_oss_getsong(struct pcm_channel *wrch, struct pcm_channel > *rdch, oss_longname_t *song);https://www.leidinger.net/FreeBSD/dox/dev_sound/html/ > static int dsp_oss_setsong(struct pcm_channel *wrch, struct pcm_channel > *rdch, oss_longname_t *song); > static int dsp_oss_setname(struct pcm_channel *wrch, struct pcm_channel > *rdch, oss_longname_t *name); > #endif > and also dsp_oss_setchnorder(). > > Maybe you are interested to un-stub them. Yeap. > > Widely-used existing codebases that can benefit from oss(3) are virtual > > oss and Mozilla’s cubeb oss audio framework, > > which are also great sources of inspiration for features included in > > oss(3). > > VirtualOSS is now unmaintained (the author died). Maybe we want to adopt it > into the base? So, I am totally on board with this idea, in fact, taking over maintenance of virtual_oss and porting it to base was one of the project's initial goals, however I realized it might need considerable effort to do so, due to the fact it uses external libraries (fftw and libsamplerate IIRC), which, as I mentioned above, might not be the wisest allocation of resources in this case, considering the scope of the project is quite large already. My current plan is to work on the existing deliverables, and if time allows, look into how virtual_oss can be ported to base. > > Bluetooth device management utility > > Someone started with a bluetooth daemon a while ago. It sounds like this and > your proposal share a common goal. No idea what the state of it is, but > maybe you want to check it out: > https://lists.freebsd.org/archives/freebsd-bluetooth/2022-August/000021.html I am aware of this project and plan to use some of its ideas as inspiration, although I find it to be quite overengineered in my humble opinion. > > Documentation > > > Some parts of the kernel sound code contain docs written in doxygen syntax. > A rendered version of it (if there is no error in the daily generation for > -current) is available at > https://www.leidinger.net/FreeBSD/dox/dev_sound/html/ > and the corresponding TODO markup is rendered at > https://www.leidinger.net/FreeBSD/dox/dev_sound/html/dd/da0/todo.html > an example of the function docs (for dsp_oss_syncgroup()) is at > https://www.leidinger.net/FreeBSD/dox/dev_sound/html/d5/d3b/dsp_8c.html#a304ece74c26d57a7df3ab5f104a3feff > > It would be nice if changes to the kernel maintain/add to the doxygen > markup. That's a great idea. I've already been using this page to navigate through the sound code more easily, so that's definitely something worth adding to. We'll stay in touch for when the time comes. Christos From nobody Thu Dec 14 23:39:33 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SrpjN15n1z53wj0 for ; Thu, 14 Dec 2023 23:39:36 +0000 (UTC) (envelope-from christos@freebsd.org) Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SrpjM5r4Lz3NhR; Thu, 14 Dec 2023 23:39:35 +0000 (UTC) (envelope-from christos@freebsd.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=mail; bh=DPMyMvlL0RGO9Et CPUtv7jUH9rjh7fPo6ALzj3NarxQ=; h=in-reply-to:references:subject:cc:to: from:date; d=margiolis.net; b=SF3ApjZ7P7Q444rAC9bKqVcLJ7fBdRnWeZBxs8Tn SYFHDD9KJVQeDVZD7hx+yIEjAwZif22clM3p1EncUnvz+zCqqES1Gk6KxBiTRH3i+pzKfS pedww9kZFWYa20L1dq9vKLNf/OKkhFgpk2Ve5/Jh+LukD9qElw71CT0GcpKqM= Received: from pleb (ppp-94-66-59-140.home.otenet.gr [94.66.59.140]) by margiolis.net (OpenSMTPD) with ESMTPSA id a97635e6 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Thu, 14 Dec 2023 23:39:33 +0000 (UTC) Date: Fri, 15 Dec 2023 01:39:33 +0200 From: Christos Margiolis To: Baptiste Daroussin Cc: freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack Message-ID: References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca> <5gncptsagv7vr6omipmttdel73uq3dx3gvjz3nsvsleqlmqdmu@denmsyow3yzj> List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5gncptsagv7vr6omipmttdel73uq3dx3gvjz3nsvsleqlmqdmu@denmsyow3yzj> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:95.179.144.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SrpjM5r4Lz3NhR Hello Baptiste, Baptiste Daroussin wrote: > Another issue which is painful with uaudio, more and more laptops have > uaudio devices by default instead of hda, and uaudio is not able to > suspend/resume if something is consuming it. > > This is the only hotpluggable device we have for snd card, when one is > going to suspend, the device is being detached not suspended (because > usb) and the decatch procedure goes through the pcm_unregister > function which loops forever hoping the application using the device > will die, which never happens, so suspend ends up in an infinite loop > in the kernel. > > Note the same happen if you disconnect any uaudio device while an > application is using it. Yeap, this is what I was mostly referring to when I wrote "Other USB audio bugs include 1) those mentioned in the snd uaudio(4) man page". Christos From nobody Fri Dec 15 08:27:45 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ss2S141GGz54TFk for ; Fri, 15 Dec 2023 08:28:49 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ss2S06sSJz3FjY; Fri, 15 Dec 2023 08:28:48 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1702628916; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=klS2+SCrep7OjLOg7KkPkwUQiiw+5jffnsnYTFz3qrA=; b=WAQWoX6ihbi5sDi4x0CK+1n55jzMzgfFAxtIWU5y+GKwbfuINcrR67LUjTso7TOknCMLao YRDw0gXDOlCWM5tqnO1lSu9skwc3xomDuSxDW4cbmgKegwRgmGNnLxYPL2jIEiTxBqRjqT rMRYQAJtxakaTSm7j95kiwQH+jacDEZUnp9kuqOiIHrSadsICTBZfDCfWICjoO+fBisllM 6kKxg0chq4/yQZ/IOSf7rxyGvoUTfbBVzo5xz6NehRERYhmZZOZCpMSgrSg1YolRig7jOP JCmQGOMUFMDnTv/7Y7q+rt/bj3zYgYUn02f+DgTGy3+dKhGi6UgR0inxpontwg== Date: Fri, 15 Dec 2023 09:27:45 +0100 From: Alexander Leidinger To: Christos Margiolis Cc: freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack In-Reply-To: References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca> <5240adad4ff5b341756809fe12d362c9@Leidinger.net> Message-ID: <7676e8efb575ee54c948ba3a1c7c364c@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_235c1670cb73639a71a1dadfe8e0b354"; micalg=pgp-sha256 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Ss2S06sSJz3FjY This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_235c1670cb73639a71a1dadfe8e0b354 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2023-12-15 00:34, schrieb Christos Margiolis: > Hello Alexander, > > Alexander Leidinger wrote: >> The dsp deices are clonable due to the virtualisation and auto-mixing >> into >> the hardware in the kernel. To my understanding the midi devices are >> not >> clonable as there is no generic way we could mix several outputs from >> programs into one hardware channel. > > Is there any other way we can achieve the functionality mentioned in > the > proposal though (i.e opening the same MIDI device from more than 1 > application at the same time)? Theoretically I could imagine that we could map MIDI channels to FreeBSD MIDI devices (e.g. midi0 sees only channel X and midi1 sees only channel Y, so program A could react only to messages on channel X and doesn't see channel Y, and program B can only send to channel Y). How much of a MIDI engine would need to be added/changed in the FreeBSD kernel to be able to do that, and what the userland side of this would/should/could look like, I have no idea. I don't have enough knowledge about MIDI in this regard. >> > Widely-used existing codebases that can benefit from oss(3) are virtual >> > oss and Mozilla’s cubeb oss audio framework, >> > which are also great sources of inspiration for features included in >> > oss(3). >> >> VirtualOSS is now unmaintained (the author died). Maybe we want to >> adopt it >> into the base? > > So, I am totally on board with this idea, in fact, taking over > maintenance of virtual_oss and porting it to base was one of the > project's initial goals, however I realized it might need considerable > effort to do so, due to the fact it uses external libraries (fftw and > libsamplerate IIRC), which, as I mentioned above, might not be the > wisest allocation of resources in this case, considering the scope of > the project is quite large already. My current plan is to work on the > existing deliverables, and if time allows, look into how virtual_oss > can > be ported to base. I could imagine something extensible which provides base features in the base systems and plugins via ports. Keeping it entirely in ports with some kind of support from the base system userland utilities of this project may also be possible (maybe via some kind of plugin system for the base userland tools). What I mention(ed) are simply ideas. I do not want to propose priorities or changes of the scope / deliverables. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_235c1670cb73639a71a1dadfe8e0b354 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmV8DhIACgkQEg2wmwP4 2IYGhRAAh6F0HlP6nUa5wrFXIXRM7kbj8eH3Bd7YQPm6wNHYuaEb40AKbZU5/syW qo4Ceux4EmC/9p8lPUvHB2g8FZycYkJa4AcarZPpaa86wui/S93YXNW8PjcEEQP+ xakZI4bd0U1knyF9xIBemCc+UkC42I7WLltykFzqA8i1+o0I1btdnbH8vrcjvkSC CNPQ7fZnigeAcAw6Qf2+62USSAKuPJ2hn3F1Z28I3K0X0VqFdvyLPEbc8jnFsOMO zM6R24Iysr6+rvIU+uW4L+JAvixhBee5C+L8jccFR7IQGyDfYSgVI8E0xY3sJhDg xOep5oe4G81q9zddJ0cBKoMC4ve6DqUoNMKwp0U+LgnbdbCyJJ8375MSDEZfuK5D q1plGrtjmPBqII/AfEGc5dGPOFURV0B+b04ecVbe4wShGuYHwLBYy7Na2+UQfUXn J2R0FrMBHmV2OVrOCGnFI1Kx0EwwMF5eUxT5gFzEjRn6oDPkp72UfNnRnPvgMx1T k02qgHicQJucE12gQQH2AJm9del3q3k3p7pbHMs+kdQOLrFZBgWA6NXMAvOwihoM zzFBhdJlIdbGpLNmpkgBqYAmnoORoSPljL2zWubYQg4K66exGSaDaUUBSyvOAqet FeXngDd8+iIdDvkF5o8H0GxZu74Wt96ARjNq6Gu+OGz3lwJ4sMU= =H6rB -----END PGP SIGNATURE----- --=_235c1670cb73639a71a1dadfe8e0b354-- From nobody Fri Dec 15 09:42:58 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ss46J6dr7z54XqH for ; Fri, 15 Dec 2023 09:43:36 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ss46J1fVrz3MCs for ; Fri, 15 Dec 2023 09:43:36 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=nCSL4pic; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-548ce39b101so515201a12.2 for ; Fri, 15 Dec 2023 01:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702633414; x=1703238214; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=KK9RiMk+DqN9yRHt0s0O4e8+pQst6gmsTzponeVrIdI=; b=nCSL4picCTQy7sX41rbhsJetpfLTmenco1kZH6iOyiw2Fl7IHd+JL3iBJ1l+yCfhw9 3xtmSlNouvaj29lNGSuVLg8nPFRGgyn69LD5eemIo5jNKhZuex12heR/RoJI9fa5zlRV LGaIW8kSbeAfjg9TLkY/bgpD0yaZC2y+zEhfFc/zut5nZeUP++1tWq1WtYatwyJGDfga zDNW2bz+SkvpXslmEzWCMk1zo+0F4D2VXM73UQ+c8eG79hGcQNrTeDBpl+LLq40+Xsll Rb+2pQw+4tK4sIlCZ/oYvPBOcQckpqfmmWVAMXViLHfIdjyBwaJofwKWotGuGcJHPxlr nyQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702633414; x=1703238214; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KK9RiMk+DqN9yRHt0s0O4e8+pQst6gmsTzponeVrIdI=; b=HUBJ7JLcV0+kpTwf+ZhL9dqD3vnxvlfcIu/O0iVrEaLRfuV+2slrhxeTKWLtpR0j/t aaBek798X2gxLzZMbwfagFHJnhIw0Ypi4m/gniq5LjRqny2cGGhLzNS9lq3Z3Ksk3uTf FNZdgA30NQ5O+FnzcUhk+3eX9VZd5kZeA8YLB9AO/vPj/z9TxyhVNeyRLrVMlRxlT0Vy CxJrqfF15oev+IA9gliYNu0A71wTnhHNk9XNiv+wQUynaiNBWsuEK4sIzk8p8hIWqGsr +AnYDHRy7hMskVR+15ys9iPCFj/OwWTzem8yFN6eFDsKgDNHgUS3MLkSu1AQ5CgHg5Nf 4Row== X-Gm-Message-State: AOJu0YwZAHr5G39tf/hyJEIvsuFrllj7z9h8caDbTHr/+fehoClLzX5u 8/DaIgNdXf31VRSt/Xyojzc8/flIhkTNRQrXvNM7k8g7doiKDQ== X-Google-Smtp-Source: AGHT+IES0RqbrlB5ZwEr1EbXg6fIJ8WizfeYlIznM/brfYXkWNGVVCf8PU0ebudLgA8n5F+J9naZU/3Fpccm5Qinbnw= X-Received: by 2002:a17:907:e88:b0:a19:9b79:8b43 with SMTP id ho8-20020a1709070e8800b00a199b798b43mr4561659ejc.84.1702633414353; Fri, 15 Dec 2023 01:43:34 -0800 (PST) List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Fri, 15 Dec 2023 10:42:58 +0100 Message-ID: Subject: vlc bug : it crashes when I open a video on a disk "formatted" with ZFS on FreeBSD 14.0-CURRENT To: freebsd-multimedia@freebsd.org Content-Type: multipart/alternative; boundary="000000000000d866bf060c893b67" X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-multimedia@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org] X-Rspamd-Queue-Id: 4Ss46J1fVrz3MCs X-Spamd-Bar: --- --000000000000d866bf060c893b67 Content-Type: text/plain; charset="UTF-8" Hello. I've stored my videos on a disk that has ZFS fs. When I try to open a video with vlc as a normal user,vlc closes after some seconds and I see this message on the terminal : VLC media player 3.0.20 Vetinari (revision 963fa2817415) [0000000814c66ae0] avcodec decoder: Using NVIDIA VDPAU Driver Shared Library 535.104.05 Sat Aug 19 00:39:34 UTC 2023 for hardware decoding and vlc produces a core file because it crashes. If you want to explore it,I can send it to you. Anyway It seems to me that there could be a bug in vlc,because I've installed correctly the nvidia driver + CUDA on my system (FreeBSD 14.0-CURRENT) : $ nvidia-smi Fri Dec 15 10:40:02 2023 +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: N/A | |-----------------------------------------+----------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+======================+======================| | 0 NVIDIA GeForce GTX 1060 3GB Off | 00000000:01:00.0 On | N/A | | 57% 43C P0 30W / 120W | 431MiB / 3072MiB | 0% Default | | | | N/A | +-----------------------------------------+----------------------+----------------------+ +---------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=======================================================================================| | 0 N/A N/A 7518 G /usr/local/libexec/Xorg 172MiB | | 0 N/A N/A 7609 G xfwm4 2MiB | | 0 N/A N/A 8219 G firefox 253MiB | +---------------------------------------------------------------------------------------+ -- Mario. --000000000000d866bf060c893b67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdj5IZWxsby48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkmIzM5 O3ZlIHN0b3JlZCBteSB2aWRlb3Mgb24gYSBkaXNrIHRoYXQgaGFzIFpGUyBmcy4gV2hlbiBJIHRy eSB0byBvcGVuIGEgdmlkZW8gd2l0aCB2bGMgYXMgYSBub3JtYWwgdXNlcix2bGMgY2xvc2VzIGFm dGVyIHNvbWUgc2Vjb25kcyBhbmQgSSBzZWUgdGhpcyBtZXNzYWdlIG9uIHRoZSB0ZXJtaW5hbCA6 PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48Zm9udCBzaXplPSI2Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6bW9ub3NwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtiYWNrZ3Jv dW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPlZMQyBtZWRpYSBwbGF5ZXIgMy4wLjIwIFZldGlu YXJpIChyZXZpc2lvbiA5NjNmYTI4MTc0MTUpDQo8L3NwYW4+PGJyPls8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZDtjb2xvcjpyZ2IoODQsMjU1LDg0KTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigy NTUsMjU1LDI1NSkiPjAwMDAwMDA4MTRjNjZhZTA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJn YigwLDAsMCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj5dIGF2Y29kZWMgZGVj b2RlcjogPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkO2NvbG9yOnJnYigwLDAs MCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj5Vc2luZyBOVklESUEgVkRQQVUg RHJpdmVyIFNoYXJlZCBMaWJyYXJ5IMKgNTM1LjEwNC4wNSBTYXQgQXVnIDE5PC9zcGFuPiAwMDoz OTozNCBVVEMgMjAyMyBmb3IgaGFyZHdhcmUgZGVjb2Rpbmc8YnI+PC9zcGFuPjwvZm9udD48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PmFuZCB2bGMgcHJvZHVjZXMgYSBjb3JlIGZpbGUgYmVjYXVz ZSBpdCBjcmFzaGVzLiBJZiB5b3Ugd2FudCB0byBleHBsb3JlIGl0LEkgY2FuIHNlbmQgaXQgdG8g eW91LiBBbnl3YXkgSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGVyZSBjb3VsZCBiZSBhIGJ1ZyBpbiB2 bGMsYmVjYXVzZSBJJiMzOTt2ZSBpbnN0YWxsZWQgY29ycmVjdGx5IHRoZSBudmlkaWEgZHJpdmVy ICsgQ1VEQSBvbiBteSBzeXN0ZW0gKEZyZWVCU0QgMTQuMC1DVVJSRU5UKSA6PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Om1vbm9zcGFjZSI+PGZv bnQgc2l6ZT0iNCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7YmFja2dyb3VuZC1jb2xv cjpyZ2IoMjU1LDI1NSwyNTUpIj4kIG52aWRpYS1zbWkNCjwvc3Bhbj48YnI+RnJpIERlYyAxNSAx MDo0MDowMiAyMDIzIMKgwqDCoMKgwqDCoMKgPGJyPistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQo8YnI+fCBOVklESUEtU01JIDUzNS4xMDQuMDUgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgRHJpdmVyIFZlcnNpb246IDUzNS4xMDQuMDUgwqDCoENVREEgVmVyc2lvbjogTi9BIMKgwqDC oMKgwqB8DQo8YnI+fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCjxicj58IEdQVSDC oE5hbWUgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBQZXJzaXN0ZW5jZS1NIHwgQnVz LUlkIMKgwqDCoMKgwqDCoMKgRGlzcC5BIHwgVm9sYXRpbGUgVW5jb3JyLiBFQ0MgfA0KPGJyPnwg RmFuIMKgVGVtcCDCoMKgUGVyZiDCoMKgwqDCoMKgwqDCoMKgwqBQd3I6VXNhZ2UvQ2FwIHwgwqDC oMKgwqDCoMKgwqDCoE1lbW9yeS1Vc2FnZSB8IEdQVS1VdGlsIMKgQ29tcHV0ZSBNLiB8DQo8YnI+ fCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHwgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgfCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgTUlHIE0uIHwNCjxicj58 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0rPT09PT09PT09PT09PT09 PT09PT09PSs9PT09PT09PT09PT09PT09PT09PT09fA0KPGJyPnwgwqDCoDAgwqBOVklESUEgR2VG b3JjZSBHVFggMTA2MCAzR0IgwqDCoMKgT2ZmIHwgMDAwMDAwMDA6MDE6MDAuMCDCoE9uIHwgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoE4vQSB8DQo8YnI+fCA1NyUgwqDCoDQzQyDC oMKgwqBQMCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDMwVyAvIDEyMFcgfCDCoMKgwqA0MzFN aUIgLyDCoDMwNzJNaUIgfCDCoMKgwqDCoMKgMCUgwqDCoMKgwqDCoERlZmF1bHQgfA0KPGJyPnwg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoHwgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoE4vQSB8DQo8YnI+ Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCjxicj4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxicj4rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPGJyPnwgUHJvY2Vzc2VzOiDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8DQo8YnI+fCDCoEdQVSDCoMKgR0kgwqDCoENJIMKgwqDC oMKgwqDCoMKgUElEIMKgwqBUeXBlIMKgwqBQcm9jZXNzIG5hbWUgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgR1BVIE1lbW9yeSB8DQo8YnI+fCDC oMKgwqDCoMKgwqDCoElEIMKgwqBJRCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBVc2FnZSDCoMKgwqDCoMKgfA0KPGJyPnw9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT18DQo8YnI+fCDCoMKgwqAwIMKgwqBOL0EgwqBOL0Eg wqDCoMKgwqDCoDc1MTggwqDCoMKgwqDCoEcgwqDCoC91c3IvbG9jYWwvbGliZXhlYy9Yb3JnIMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAxNzJNaUIgfA0KPGJyPnwgwqDC oMKgMCDCoMKgTi9BIMKgTi9BIMKgwqDCoMKgwqA3NjA5IMKgwqDCoMKgwqBHIMKgwqB4ZndtNCDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoDJNaUIgfA0KPGJyPnwgwqDCoMKgMCDCoMKgTi9BIMKgTi9B IMKgwqDCoMKgwqA4MjE5IMKgwqDCoMKgwqBHIMKgwqBmaXJlZm94IMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDI1 M01pQiB8DQo8YnI+Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8YnI+PC9mb250Pg0K PC9zcGFuPjxicj48c3BhbiBjbGFzcz0iZ21haWxfc2lnbmF0dXJlX3ByZWZpeCI+LS0gPC9zcGFu Pjxicj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfc2lnbmF0dXJlIiBkYXRhLXNtYXJ0bWFp bD0iZ21haWxfc2lnbmF0dXJlIj5NYXJpby48YnI+PC9kaXY+PC9kaXY+PC9kaXY+DQo= --000000000000d866bf060c893b67-- From nobody Fri Dec 15 09:56:59 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ss4QY4Tgqz54YM7 for ; Fri, 15 Dec 2023 09:57:41 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ss4QX6jgDz3NK9 for ; Fri, 15 Dec 2023 09:57:40 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=VZqJPrpl; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a22eba5a290so55893566b.3 for ; Fri, 15 Dec 2023 01:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702634256; x=1703239056; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=BTAokIPsoXt+m2S/b0zwqBD60k+W50zbfZ+gGMiBYxs=; b=VZqJPrplc0zT2aaQ5wz0w59I45zprgqdMiN2vBGGxoF0ryvuD5tnwMvC3kkA1v8deA QOazecBm51gkFKHpUWASB1ikAq1Za500iIp6sBjGOTyoYpoVhEHtezRshxt4bDoUF0j5 xHz3i0kHpjHNn1pG34ZwEE5I4fyhVCtSo5pGy+E/2dTbyKc1HfA0XsyJWiNAS5vS+9Fk u+IwSsqLhpZEWnuACtAx06J0969RJRSVVn0wYCWg9VAdmUEWRJnOEv+bpi1u8QUJum6+ OSMtiisy21J+TvR/CgGttK0UwilOd8cVhtFORfo+J8jnsb8nq40tr6DJCpojW8cGevK0 n7JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702634256; x=1703239056; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BTAokIPsoXt+m2S/b0zwqBD60k+W50zbfZ+gGMiBYxs=; b=LSivHHOVH6zlcIrMzJeQpeaDfRjB5GbUjMck/7YHKVbjTxU5/TsmkOYhyeGDUKMhFB pn4gWjGNRYrnmXhbdKnw9o2VBBOm1f3pucprkE31KqZtuzxK98iU9DyVysG+R4HKpGeE byYUK9NP6ViSNfiR3jhwhL6dume9MuTS9+egT4yJX5u90psEj7mfm6hA6OD+VN7zNCTP JOz5gzB00CAoOXyjIMVnmHyBm15i0mu4F5w9zasFGyir14eHhCm/5yMKw06aYkxK+LbR UzXKW4jxx00BEU1fbUiLkzThC7n/yXAHyAsGpG6jXzzihinMP9cJ8DGsDC3/1ybTHDiG 237A== X-Gm-Message-State: AOJu0YwZeDkuX8XhJjjZjyv4PKi63yKAWVkD7O9TFF7Kgxg52NwbACPF rW5koOzjiT9y1D1+wjEOJGzQCj7zs3rgwiN/lVMABR5uQfU= X-Google-Smtp-Source: AGHT+IEI1Jikw+zcGVgop+9F7Leovck1YSbFbJLplpfnoPzi9Ke50jmOp2+Ul/kiOR3/Bj657eLvGx9kMVSOg2Clgfw= X-Received: by 2002:a17:907:7f28:b0:a0f:42da:1710 with SMTP id qf40-20020a1709077f2800b00a0f42da1710mr7860467ejc.59.1702634255584; Fri, 15 Dec 2023 01:57:35 -0800 (PST) List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Fri, 15 Dec 2023 10:56:59 +0100 Message-ID: Subject: Re: vlc bug : it crashes when I open a video on a disk "formatted" with ZFS on FreeBSD 14.0-CURRENT To: freebsd-multimedia@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fc951e060c896d38" X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-multimedia@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org] X-Rspamd-Queue-Id: 4Ss4QX6jgDz3NK9 X-Spamd-Bar: --- --000000000000fc951e060c896d38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't know if it is correct,but vlc does not crash if I choose "VA-API video decoder",but it does if I use "VDPAU" video decoder or automatic. I would like to know if there is a problem on VLC or in my system. On Fri, Dec 15, 2023 at 10:42=E2=80=AFAM Mario Marietto wrote: > Hello. > > I've stored my videos on a disk that has ZFS fs. When I try to open a > video with vlc as a normal user,vlc closes after some seconds and I see > this message on the terminal : > > VLC media player 3.0.20 Vetinari (revision 963fa2817415) > [0000000814c66ae0] avcodec decoder: Using NVIDIA VDPAU Driver Shared > Library 535.104.05 Sat Aug 19 00:39:34 UTC 2023 for hardware decoding > > and vlc produces a core file because it crashes. If you want to explore > it,I can send it to you. Anyway It seems to me that there could be a bug = in > vlc,because I've installed correctly the nvidia driver + CUDA on my syste= m > (FreeBSD 14.0-CURRENT) : > > $ nvidia-smi > Fri Dec 15 10:40:02 2023 > +------------------------------------------------------------------------= ---------------+ > > | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA > Version: N/A | > |-----------------------------------------+----------------------+-------= ---------------+ > > | GPU Name Persistence-M | Bus-Id Disp.A | > Volatile Uncorr. ECC | > | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | > GPU-Util Compute M. | > | | | > MIG M. | > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| > > | 0 NVIDIA GeForce GTX 1060 3GB Off | 00000000:01:00.0 On | > N/A | > | 57% 43C P0 30W / 120W | 431MiB / 3072MiB | 0= % > Default | > | | | > N/A | > +-----------------------------------------+----------------------+-------= ---------------+ > > > > +------------------------------------------------------------------------= ---------------+ > > | Processes: > = | > > | GPU GI CI PID Type Process name > GPU Memory | > | ID ID > Usage | > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| > > | 0 N/A N/A 7518 G /usr/local/libexec/Xorg > 172MiB | > | 0 N/A N/A 7609 G xfwm4 > 2MiB | > | 0 N/A N/A 8219 G firefox > 253MiB | > > +------------------------------------------------------------------------= ---------------+ > > -- > Mario. > --=20 Mario. --000000000000fc951e060c896d38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SSBkb24mIzM5O3Qga25vdyBpZiBpdCBpcyBjb3JyZWN0LGJ1dCB2bGMg ZG9lcyBub3QgY3Jhc2ggaWYgSSBjaG9vc2UgJnF1b3Q7VkEtQVBJIHZpZGVvIGRlY29kZXImcXVv dDssYnV0IGl0IGRvZXMgaWYgSSB1c2UgJnF1b3Q7VkRQQVUmcXVvdDsgdmlkZW8gZGVjb2RlciBv ciBhdXRvbWF0aWMuIEkgd291bGQgbGlrZSB0byBrbm93IGlmIHRoZXJlIGlzIGEgcHJvYmxlbSBv biBWTEMgb3IgaW4gbXkgc3lzdGVtLiA8YnI+PC9kaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gRnJpLCBEZWMgMTUsIDIw MjMgYXQgMTA6NDLigK9BTSBNYXJpbyBNYXJpZXR0byAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmll dHRvMjAwOEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJpZXR0bzIwMDhAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdi KDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0ibHRyIj48ZGl2PkhlbGxv LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSYjMzk7dmUgc3RvcmVkIG15IHZpZGVvcyBvbiBh IGRpc2sgdGhhdCBoYXMgWkZTIGZzLiBXaGVuIEkgdHJ5IHRvIG9wZW4gYSB2aWRlbyB3aXRoIHZs YyBhcyBhIG5vcm1hbCB1c2VyLHZsYyBjbG9zZXMgYWZ0ZXIgc29tZSBzZWNvbmRzIGFuZCBJIHNl ZSB0aGlzIG1lc3NhZ2Ugb24gdGhlIHRlcm1pbmFsIDo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pjxmb250IHNpemU9IjYiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTptb25vc3BhY2UiPjxzcGFu IHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1 KSI+VkxDIG1lZGlhIHBsYXllciAzLjAuMjAgVmV0aW5hcmkgKHJldmlzaW9uIDk2M2ZhMjgxNzQx NSkNCjwvc3Bhbj48YnI+WzxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkO2NvbG9yOnJnYig4 NCwyNTUsODQpO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+MDAwMDAwMDgxNGM2 NmFlMDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9y OnJnYigyNTUsMjU1LDI1NSkiPl0gYXZjb2RlYyBkZWNvZGVyOiA8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQ7Y29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigy NTUsMjU1LDI1NSkiPlVzaW5nIE5WSURJQSBWRFBBVSBEcml2ZXIgU2hhcmVkIExpYnJhcnkgwqA1 MzUuMTA0LjA1IFNhdCBBdWcgMTk8L3NwYW4+IDAwOjM5OjM0IFVUQyAyMDIzIGZvciBoYXJkd2Fy ZSBkZWNvZGluZzxicj48L3NwYW4+PC9mb250PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+YW5k IHZsYyBwcm9kdWNlcyBhIGNvcmUgZmlsZSBiZWNhdXNlIGl0IGNyYXNoZXMuIElmIHlvdSB3YW50 IHRvIGV4cGxvcmUgaXQsSSBjYW4gc2VuZCBpdCB0byB5b3UuIEFueXdheSBJdCBzZWVtcyB0byBt ZSB0aGF0IHRoZXJlIGNvdWxkIGJlIGEgYnVnIGluIHZsYyxiZWNhdXNlIEkmIzM5O3ZlIGluc3Rh bGxlZCBjb3JyZWN0bHkgdGhlIG52aWRpYSBkcml2ZXIgKyBDVURBIG9uIG15IHN5c3RlbSAoRnJl ZUJTRCAxNC4wLUNVUlJFTlQpIDo8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6bW9ub3NwYWNlIj48Zm9udCBzaXplPSI0Ij48c3BhbiBzdHlsZT0i Y29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPiQgbnZp ZGlhLXNtaQ0KPC9zcGFuPjxicj5GcmkgRGVjIDE1IDEwOjQwOjAyIDIwMjMgwqDCoMKgwqDCoMKg wqA8YnI+Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCjxicj58IE5WSURJQS1TTUkg NTM1LjEwNC4wNSDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBEcml2ZXIgVmVyc2lvbjogNTM1LjEw NC4wNSDCoMKgQ1VEQSBWZXJzaW9uOiBOL0EgwqDCoMKgwqDCoHwNCjxicj58LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KPGJyPnwgR1BVIMKgTmFtZSDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoFBlcnNpc3RlbmNlLU0gfCBCdXMtSWQgwqDCoMKgwqDCoMKgwqBEaXNwLkEg fCBWb2xhdGlsZSBVbmNvcnIuIEVDQyB8DQo8YnI+fCBGYW4gwqBUZW1wIMKgwqBQZXJmIMKgwqDC oMKgwqDCoMKgwqDCoFB3cjpVc2FnZS9DYXAgfCDCoMKgwqDCoMKgwqDCoMKgTWVtb3J5LVVzYWdl IHwgR1BVLVV0aWwgwqBDb21wdXRlIE0uIHwNCjxicj58IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg fCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqBNSUcgTS4gfA0KPGJyPnw9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PSs9PT09PT09PT09PT09PT09PT09PT09Kz09PT09PT09PT09PT09PT09 PT09PT18DQo8YnI+fCDCoMKgMCDCoE5WSURJQSBHZUZvcmNlIEdUWCAxMDYwIDNHQiDCoMKgwqBP ZmYgfCAwMDAwMDAwMDowMTowMC4wIMKgT24gfCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgTi9BIHwNCjxicj58IDU3JSDCoMKgNDNDIMKgwqDCoFAwIMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgMzBXIC8gMTIwVyB8IMKgwqDCoDQzMU1pQiAvIMKgMzA3Mk1pQiB8IMKgwqDCoMKg wqAwJSDCoMKgwqDCoMKgRGVmYXVsdCB8DQo8YnI+fCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHwg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfCDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgTi9BIHwNCjxicj4rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgPGJyPistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQo8YnI+fCBQcm9jZXNzZXM6IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHwN Cjxicj58IMKgR1BVIMKgwqBHSSDCoMKgQ0kgwqDCoMKgwqDCoMKgwqBQSUQgwqDCoFR5cGUgwqDC oFByb2Nlc3MgbmFtZSDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqBHUFUgTWVtb3J5IHwNCjxicj58IMKgwqDCoMKgwqDCoMKgSUQgwqDCoElEIMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoFVzYWdlIMKgwqDCoMKgwqB8DQo8YnI+fD09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PXwNCjxicj58IMKgwqDCoDAgwqDCoE4vQSDCoE4vQSDCoMKgwqDCoMKgNzUxOCDCoMKgwqDCoMKg RyDCoMKgL3Vzci9sb2NhbC9saWJleGVjL1hvcmcgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoDE3Mk1pQiB8DQo8YnI+fCDCoMKgwqAwIMKgwqBOL0EgwqBOL0EgwqDCoMKg wqDCoDc2MDkgwqDCoMKgwqDCoEcgwqDCoHhmd200IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgMk1p QiB8DQo8YnI+fCDCoMKgwqAwIMKgwqBOL0EgwqBOL0EgwqDCoMKgwqDCoDgyMTkgwqDCoMKgwqDC oEcgwqDCoGZpcmVmb3ggwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgMjUzTWlCIHwNCjxicj4rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKzxicj48L2ZvbnQ+DQo8L3NwYW4+PGJyPjxzcGFuIGNsYXNzPSJn bWFpbF9zaWduYXR1cmVfcHJlZml4Ij4tLSA8L3NwYW4+PGJyPjxkaXYgZGlyPSJsdHIiIGNsYXNz PSJnbWFpbF9zaWduYXR1cmUiPk1hcmlvLjxicj48L2Rpdj48L2Rpdj48L2Rpdj4NCjwvYmxvY2tx dW90ZT48L2Rpdj48YnIgY2xlYXI9ImFsbCI+PGJyPjxzcGFuIGNsYXNzPSJnbWFpbF9zaWduYXR1 cmVfcHJlZml4Ij4tLSA8L3NwYW4+PGJyPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9zaWdu YXR1cmUiPk1hcmlvLjxicj48L2Rpdj4NCg== --000000000000fc951e060c896d38-- From nobody Sat Dec 16 12:27:18 2023 X-Original-To: multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sslhl64KMz53rgP for ; Sat, 16 Dec 2023 12:27:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sslhl4wq0z4SLk for ; Sat, 16 Dec 2023 12:27:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702729639; a=rsa-sha256; cv=none; b=N6N+iyqwRKUcGxC9HyDmFvsdWZAfWRCjbiJCH2pjDj5Q0gXqREwDXmWZQSN4j0FSbyL2ZQ cFMgCDkgXd+5hiPEu3PcwuE4MpRB/8oB02VQ9obZKaUENGK3LvK+jeRkYiJPZ+CKejf4Px 4ggYol/J0WIg9tuV4AZvJ2mwL0hcJ4z7rBDJSPfhVX1RQNhC1VDm+BqY9l/mBq82TL0xKW +oDv7bELMGdbWzu3g5JOXVg6H1OkeU1jB2OQdyQtLZ8/GV7UUN3yjipDlyQLezCuwdF+V9 r/ZJvPrHy63ccHSwhbraeppUEjRXQqAx36BSx2qCuYJDTiyDdHOLv8lIkyx01g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702729639; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ahpmm5I+IM/kTOTOg1G8z1E0QB5pFN8x1C/5xTaUslY=; b=Ml56Ja6Wpp8Y8U3/1/OFptetfG6NIC0ad9XQl0jN6yLqxXlFNmjn4TI6ceTGfAKuRgl1Tj sqn06LjIKXg0bmDmUp//D7IKNB8JitWU2l67LekZ5ugBqWvd71lqSeKKHiy+p2Kh2xtiwE Rd3B3vkr4+5xHIr6t4qHL+cujqz751yyfemrPcP/swIf4UK15KkBcK/ZCFjOeG7FOOgTtF t+aFJeTmga+p2fQ/VEewQROP+VFtERdU/ue2ulxChTqC6m3oEUz2r/r7A5vzue4TV8uaKy 0ynjoSvrTGNSCy4ee0/NU8IG22Q7BDI6y3eVhuyv1haNfWfi8jrh1tTt5p6GfQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Sslhl3r4MztrC for ; Sat, 16 Dec 2023 12:27:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3BGCRJas014393 for ; Sat, 16 Dec 2023 12:27:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3BGCRJvj014392 for multimedia@FreeBSD.org; Sat, 16 Dec 2023 12:27:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 271559] snd_uaudio(4): Creative Katana V2X garbled audio Date: Sat, 16 Dec 2023 12:27:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ehaupt@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271559 Emanuel Haupt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |FIXED --- Comment #21 from Emanuel Haupt --- It's mixed feelings closing this ticket. Hans Petter Selasky helped a lot in solving it, but now he's not here, which is very sad. Florian, your help in this was also important. Thank you. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Dec 16 14:19:22 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SspB926Yfz540HC for ; Sat, 16 Dec 2023 14:19:29 +0000 (UTC) (envelope-from dev@submerge.ch) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SspB744lpz4gl5 for ; Sat, 16 Dec 2023 14:19:27 +0000 (UTC) (envelope-from dev@submerge.ch) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of dev@submerge.ch designates 2001:8e0:40:325::36 as permitted sender) smtp.mailfrom=dev@submerge.ch; dmarc=none Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B13FA340651; Sat, 16 Dec 2023 15:19:23 +0100 (CET) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/28147.32594); Sat, 16 Dec 2023 15:19:23 +0100 (CET) Received: from interway.li (sendai-nord.iway.ch [212.25.24.38]) by gozo.iway.ch (Postfix) with ESMTP; Sat, 16 Dec 2023 15:19:23 +0100 (CET) Received: from [145.40.196.39] (account fw@submerge.ch HELO x230.localnet) by sendai-nord.interway.li (CommuniGate Pro SMTP 7.1.0) with ESMTPSA id 253877949; Sat, 16 Dec 2023 15:19:23 +0100 From: Florian Walpen To: Joseph Mingrone , freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack Date: Sat, 16 Dec 2023 15:19:22 +0100 Message-ID: <6705256.qJWK8QVVMX@x230> In-Reply-To: <86y1dxpjzy.fsf@phe.ftfl.ca> References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca> List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_LONG(-0.99)[-0.989]; NEURAL_HAM_SHORT(-0.96)[-0.963]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_IN_DNSWL_LOW(-0.20)[2001:8e0:40:325::36:from,212.25.24.38:received]; R_SPF_ALLOW(-0.20)[+ip6:2001:8e0::/32]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:8758, ipnet:2001:8e0::/32, country:CH]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[submerge.ch]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SspB744lpz4gl5 X-Spamd-Bar: -- On Thursday, December 14, 2023 3:59:13 AM CET Joseph Mingrone wrote: > Re-sending the text because the original contained a few errors, the worst > being broken URLs from a PDF to text conversion. >=20 > Hello, >=20 > The FreeBSD Foundation will be contracting out work on FreeBSD's audio > stack. If you have any comments about the work, please share them before > next Wednesday, December 20. >=20 > Joe Any effort in this department is very welcome indeed. I seem to be in the=20 target group of this project - I'm the maintainer of audio/ardour and audio/ jack, and I wrote both the current and the upcoming (low latency) OSS backe= nd=20 for Jack. Currently I am working on an improved driver for snd_hdspe(4). >=20 > * Project Description >=20 > The end goal of the project is to provide FreeBSD audio developers with > useful tools and frameworks to make sound development on FreeBSD easier, > without having to resort to custom solutions for everything. >=20 > On the user side, FreeBSD will ship with a more stable audio stack and a > larger collection of userland programs, making for a more coherent > ecosystem in general. OSS generally does not come with many native tools > except mixer(8), and users have to resort to using tools from multiple > different audio systems (ALSA, PulseAudio, sndio) to compensate. > Additionally, I think the introduction of new development frameworks will > encourage more native audio development, which is going to be especially > beneficial for people - me included - who want to use FreeBSD for music > production. Let's be realistic here. The OSS API is a dead end in the middle to long te= rm.=20 It's neither widely used nor particularly well suited for modern hardware. = And=20 it's conceptually broken on many levels, including parameter negotiation,=20 consistency of parameters, buffer and latency management, error handling. =46ixes and usability improvements are a good thing. But we have to think a= bout=20 what to replace the OSS API with and how much time we still want to invest= =20 into the OSS ecosystem. Besides that, for most users the OSS API is just a sink for their primary=20 sound server like PulseAudio, sndio, pipewire. These will not go away. I'd= =20 focus on complementary features and coexistence here. Music production is a very different beast altogether. It'll always need so= me=20 more knowledge and custom solutions. >=20 > snd uaudio(4) fixes >=20 > The project will also address bugs in the USB audio driver, snd uaudio(4), > which I have been able to reproduce using my Focusrite Scarlett USB sound > card, with the most prominent and consistent one being noise produced > during the first 12 seconds of playback and when moving along a > track/video. If the user tries to move forward multiple times in a short > time window, the audio device most of the time becomes unusable (i.e no > audio) and it has to be replugged. Though this issue is largely bypassed = if > audio is routed to the USB device through virtual oss, this is still a bug > that needs to be addressed. =46rom the description here this sounds more like an issue with the player = or=20 the vchan feeders, given that virtual_oss doesn't produce noise. Did you fi= le=20 a bug report? >=20 > Related bug reports include: >=20 > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257082 > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194527 I'm not convinced that these are related. There's probably better examples = for=20 snd_uaudio problems, if you skim the bug reports. >=20 > Initially I am going to test whether the open() and read() routines cause > this issue, as DTrace suggests that this happens around the same time > open(2) or the first read(2) is called. As mentioned in the previous > paragraph, virtual oss partially fixes this issue, so I would like to > investigate and understand why, and maybe find the root cause that way. > Another source of information will be Linux=E2=80=99s Scarlett and USB au= dio > drivers which, as far as I know, do not have this issue. Most problems I've seen are about bad vchan constellations. A good=20 troubleshooting checklist would be of great help for bug reports, something= =20 along the lines of # sysctl hw.snd.verbose=3D2 # cat /dev/sndstat # ... and some more user friendly output from /dev/sndstat etc. My Scarlett18i20 works fine, BTW. Maybe a different hardware generation=20 though. >=20 > Other USB audio bugs include 1) those mentioned in the snd uaudio(4) man > page, 2) snd uaudio(4) not passing enough information (e.g device name, > associated device in /dev, and more) to the OSS API, 3) no explicit list = of > supported sound cards. >=20 > MIDI device cloning >=20 > Unlike DSP devices, sound(4) does not allow cloning of MIDI devices, mean= ing > applications cannot open the same MIDI device multiple times (e.g when > recording more than one track with the same device). This can be verified > by tracing the dsp clone() routine found in sys/dev/sound/pcm/dsp.c, which > is triggered during a dev clone EVENTHANDLER(9) event. For example, given= a > /dev/dsp8.0 device, trying to cat(1) /dev/dsp8.1 would trigger dsp clone() > and create it on the fly (see FILES section in sound(4) man page). Howeve= r, > doing that with a MIDI device would trigger the handler, but result in an > error, as MIDI devices do not support cloning. To fix this, the MIDI code > will be patched to use the snd clone framework used for cloning DSP > devices. Is there really demand for this? Multiplexing MIDI is usually done in the=20 sound server or DAW. And ALSA MIDI ports can be cloned, AFAIK, so audio=20 software ported from Linux will be fine without it. >=20 > Other kernel improvements >=20 > Other improvements to the kernel code include 1) better-syncing with the > 4Front OSSv4 API, 2) addressing open bug reports, 3) making optimizations > where possible. Again, OSSv4 compatibility won't help much, it's basically abandoned by aud= io=20 software developers. Apart from open bug reports there's also missing keven= t=20 support (instead of poll() being the only option), or the buffer / blocksiz= e=20 based latency setting which is conceptually broken. I can give more details= on=20 these topics if there's interest. >=20 > oss(3) >=20 > Following the motivation behind mixer(3), which was to make OSS mixer > development more pleasant and easier, I will implement an oss(3) library, > responsible for handling the audio device=E2=80=99s state. oss(3) will se= rve as a > unified interface for OSS audio and MIDI developers and allow for quicker > application development, like Digital Audio Workstations, instrument > effects, audio servers, and general utilities. >=20 > Widely-used existing codebases that can benefit from oss(3) are virtual o= ss > and Mozilla=E2=80=99s cubeb oss audio framework, which are also great sou= rces of > inspiration for features included in oss(3). What's the scope of this library? Main PCM devices, virtual PCM devices,=20 hardware devices? Settings and state only, or also playback and recording=20 operation? Beware that there's a great variety of operation strategies for different u= se=20 cases. With a simple poll() based read() / write() at one end of the spectr= um,=20 and something like my new Jack OSS backend on the other end. It's timer bas= ed,=20 preferably mmap()ed, uses its own buffer management and strives to keep=20 latency reproducible within +/- 1ms. The backend code is here: https://github.com/0EVSG/sosso Due to different requirements, it will be difficult to simplify much of the= =20 OSS device setup while still catering to all operation strategies. >=20 > audio(8) >=20 > FreeBSD lacks an easy-to-use audio device handling utility similar to > mixer(8), but for the device-side of OSS, like OpenBSD=E2=80=99s audioctl= (8). Such > a utility will make use of the new oss(3) library, and offer a cleaner and > user-friendlier interface, concentrating all useful - but scattered - > information currently provided by /dev/sndstat, hw.snd, dev.pcm and > hw.usb.uaudio, the OSS API into the output of a single application. Many of the sysctls mentioned here are not dynamic and only apply on playba= ck=20 / recording restart or device attach. That could limit this tool's usefulne= ss. =46or reference, this part of my Jack on FreeBSD notes should give you an=20 overview of knobs that are beneficial for music production: https://github.com/0EVSG/freebsd_jack_notes#system-settings >=20 > Hot-swapping >=20 > Users of plain OSS, that is, without virtual oss, will have noticed that > hot-swapping audio devices (i.e changing the default unit, hw.snd.default > unit) mid-track does not work and sound keeps coming out of the previous > device until the track is restarted. This is because applications open(2) > the device at the start of playback and close(2) it when the track has > stopped. virtual oss(8) can create a virtual audio device responsible for > routing audio to the appropriate physical audio device. The device(s) sou= nd > is routed to can be changed at run-time using virtual oss cmd(8). >=20 > This method has the advantage that sound can be re-routed to different > devices while applications keep the same /dev/dsp open; virtual oss(8) wi= ll > make any necessary conversions on the fly and redirect audio to the new > device without requiring a restart of the track/application. >=20 > This functionality will be embedded in either mixer(8) or the new audio(8) > program. What you outline here is a complete sound server, but it doesn't tell how y= ou=20 want to implement that. Extend the vchan infrastructure, autostart virtual_= oss=20 on all PCM devices, or something else? In many use cases this just duplicates the sound server that sits on top of= =20 the dsp device. At worst it compromises quality and latency because of=20 conversions and routing buffers. As a provocative question, wouldn't the=20 average user be served better if we just implemented full pipewire support,= =20 going forward? >=20 > Testing >=20 > Testing will be done on both VMs and actual hardware, with each patch > build-tested locally and on the FreeBSD cluster. The project will require > testing some of the kernel patches with multiple different audio devices. > Additionally, there will be new tests written for the FreeBSD test suite, > for both the kernel and userland parts. >=20 > The audio driver will be tested by writing a test program to go through m= ost > of the IOCTLs provided to by the driver, to both confirm that the > information returned is correct, and also to make sure that users cannot > pass values that would break the driver. Exact cases will be considered > further down the project. You mean IOCTLs provided by the dsp devices? On a dummy driver? Because the= =20 hardware drivers are usually well separated in kernel modules, which means= =20 they can be tested separately. Sorry to sound a bit negative here, but some of the objectives look rather= =20 vague to me and I think another iteration of problem analysis and scope=20 definition would increase chances of success. Anyway, I'm glad to help if you have questions or want to discuss something. Regards, =46lorian From nobody Sat Dec 16 16:06:12 2023 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SsrYV2pc3z546sh for ; Sat, 16 Dec 2023 16:06:22 +0000 (UTC) (envelope-from christos@freebsd.org) Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SsrYT10LFz4ssv for ; Sat, 16 Dec 2023 16:06:21 +0000 (UTC) (envelope-from christos@freebsd.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=mail; bh=+74xuaJlcDVvlh1 oVdnoqSaALwbZYr5eqrFZRkDupF4=; h=in-reply-to:references:subject:cc:to: from:date; d=margiolis.net; b=VfHvUeLCo1zlojCqMXUuWfoJG/O174EN3rodGF5e 5LJWOnb2Zp/ac9U1h3+1dqq238Vh/1OfQ2f0H+zcehjKJdD34epZcUTPyqFseCJjQTMcwU 03i5SF6OqNf/+bzW8OcCtDKwEDEJWryQOzNF7/iu/Vic8c9kHaSmGqE1RSqnI= Received: from pleb (ppp-94-66-59-140.home.otenet.gr [94.66.59.140]) by margiolis.net (OpenSMTPD) with ESMTPSA id 798a88fd (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Sat, 16 Dec 2023 16:06:13 +0000 (UTC) Date: Sat, 16 Dec 2023 18:06:12 +0200 From: Christos Margiolis To: Florian Walpen Cc: Joseph Mingrone , freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack Message-ID: References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca> <6705256.qJWK8QVVMX@x230> List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6705256.qJWK8QVVMX@x230> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:95.179.144.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SsrYT10LFz4ssv Hello Florian, Florian Walpen wrote: > Let's be realistic here. The OSS API is a dead end in the middle to long term. > It's neither widely used nor particularly well suited for modern hardware. And > it's conceptually broken on many levels, including parameter negotiation, > consistency of parameters, buffer and latency management, error handling. > > Fixes and usability improvements are a good thing. But we have to think about > what to replace the OSS API with and how much time we still want to invest > into the OSS ecosystem. This is something I have been thinking about even before the proposal, but replacing OSS with an existing sound system (sndio maybe?), or rolling our own one, is probably too large of an endeavour, considering the amount of infrastructure built around OSS. That being said, I am also in favour of replacing OSS at some point, and very much willing to work on this, but it might be wiser, for now, to improve what we currently have and provide a better user-experience than leave it as-is until we decide whether we'll get rid of OSS or not. > > snd uaudio(4) fixes > > > > The project will also address bugs in the USB audio driver, snd uaudio(4), > > which I have been able to reproduce using my Focusrite Scarlett USB sound > > card, with the most prominent and consistent one being noise produced > > during the first 12 seconds of playback and when moving along a > > track/video. If the user tries to move forward multiple times in a short > > time window, the audio device most of the time becomes unusable (i.e no > > audio) and it has to be replugged. Though this issue is largely bypassed if > > audio is routed to the USB device through virtual oss, this is still a bug > > that needs to be addressed. > > From the description here this sounds more like an issue with the player or > the vchan feeders, given that virtual_oss doesn't produce noise. Did you file > a bug report? I really doubt it's the player, as this happens with pretty much any player (mpv, ncmpcpp, firefox, ...) I have tried. virtual_oss does produce noise, but only when the device is opened. > > Initially I am going to test whether the open() and read() routines cause > > this issue, as DTrace suggests that this happens around the same time > > open(2) or the first read(2) is called. As mentioned in the previous > > paragraph, virtual oss partially fixes this issue, so I would like to > > investigate and understand why, and maybe find the root cause that way. > > Another source of information will be Linux’s Scarlett and USB audio > > drivers which, as far as I know, do not have this issue. > > Most problems I've seen are about bad vchan constellations. A good > troubleshooting checklist would be of great help for bug reports, something > along the lines of > > # sysctl hw.snd.verbose=2 > # cat /dev/sndstat > # ... > > and some more user friendly output from /dev/sndstat etc. Making the verbose output of /dev/sndstat less cryptic could be a nice improvement, IMO. > > oss(3) > > What's the scope of this library? Main PCM devices, virtual PCM > devices, hardware devices? Settings and state only, or also playback > and recording operation? > > Beware that there's a great variety of operation strategies for different use > cases. With a simple poll() based read() / write() at one end of the spectrum, > and something like my new Jack OSS backend on the other end. It's timer based, > preferably mmap()ed, uses its own buffer management and strives to keep > latency reproducible within +/- 1ms. The backend code is here: > > https://github.com/0EVSG/sosso It's going to have both mmap'd and non-mmap'd buffer-management (reading, writing, splitting, merging), as well as state setting. Goran Mekić had brought up your library when we discussed this during EuroBSDCon 2023, and I think oss(3) could re-use some of the ideas implemented there, especially the low-latency mechanisms. > > audio(8) > > > > FreeBSD lacks an easy-to-use audio device handling utility similar to > > mixer(8), but for the device-side of OSS, like OpenBSD’s audioctl(8). Such > > a utility will make use of the new oss(3) library, and offer a cleaner and > > user-friendlier interface, concentrating all useful - but scattered - > > information currently provided by /dev/sndstat, hw.snd, dev.pcm and > > hw.usb.uaudio, the OSS API into the output of a single application. > > Many of the sysctls mentioned here are not dynamic and only apply on playback > / recording restart or device attach. That could limit this tool's usefulness. I am aware of this, however, it's still useful to have "everything" concertrated in one place. Sound settings on FreeBSD are really scattered IMHO. > For reference, this part of my Jack on FreeBSD notes should give you an > overview of knobs that are beneficial for music production: > > https://github.com/0EVSG/freebsd_jack_notes#system-settings Interesting, thank you. > > Hot-swapping > > > What you outline here is a complete sound server, but it doesn't tell how you > want to implement that. Extend the vchan infrastructure, autostart virtual_oss > on all PCM devices, or something else? > > In many use cases this just duplicates the sound server that sits on top of > the dsp device. At worst it compromises quality and latency because of > conversions and routing buffers. As a provocative question, wouldn't the > average user be served better if we just implemented full pipewire support, > going forward? Not really. We currently change the default unit by either doing $ mixer -d Or # sysctl hw.snd.default_unit= Which requires a track restart for the change to take effect. All that would change with my proposed solution is simply detect if virtual_oss is present, and in that case, change both the default unit through the sysctl AND switch to the wanted unit through the virtual_oss IOCTL interface so that the change takes effect immediately if we have virtual_oss running. > > Testing > > > > The audio driver will be tested by writing a test program to go through most > > of the IOCTLs provided to by the driver, to both confirm that the > > information returned is correct, and also to make sure that users cannot > > pass values that would break the driver. Exact cases will be considered > > further down the project. > > You mean IOCTLs provided by the dsp devices? On a dummy driver? Because the > hardware drivers are usually well separated in kernel modules, which means > they can be tested separately. Honestly, I am still thinking about this, so I am not exactly sure yet. Do you think there it's possible to create a reliable test case using a virtual dummy device? > Again, OSSv4 compatibility won't help much, it's basically abandoned by audio > software developers. Apart from open bug reports there's also missing kevent > support (instead of poll() being the only option), or the buffer / blocksize > based latency setting which is conceptually broken. I can give more details on > these topics if there's interest. More details would be appreciated. :) > Sorry to sound a bit negative here, but some of the objectives look rather > vague to me and I think another iteration of problem analysis and scope > definition would increase chances of success. Feedback is always welcome! From what I understand, your main sentiment is that you are against investing significant amounts of time getting more in-sync with OSSv4, as there's not enough demand for it. I do not really have any objection to this if you think there are more pressing issues that could replace this goal, so I am open to suggestions! Christos From nobody Sat Dec 16 16:20:50 2023 X-Original-To: multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SsrtG5PcYz547XL; Sat, 16 Dec 2023 16:20:54 +0000 (UTC) (envelope-from vvd@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SsrtG4yvCz3CbF; Sat, 16 Dec 2023 16:20:54 +0000 (UTC) (envelope-from vvd@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702743654; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Ue1hzjEo5vm1I1kA5C3lZK3MZL3dJOb81hjtmp16WtM=; b=iBPxlxAASDiTBEJP/StYvtrmdq8cr0fQ+RSDOos735wuLKGHPQs+q9GeGvKe1lxQr1MIxR cNCfmMBVxQ3CMCV69xmaeUJG2XMQAWfc1+MqEFjYrx/+LoSXLNTdWQKIRXT5YZHlxFsVrX 3achaHwJ8rOJAmsTahMNHxsF+9vKDYiNMR/5cBcLSTpdmgOtYCRoZUI2+4tS2PlfdBL2Ib rNzI4Y5PrlXJCTAuPVSF0RNCl3p83WJufljCHvdRf7GRWB7rAGo/WYDwjs0kKvWj53OYa6 UhWLy9AwD68E2ebrSYHzJ/5MXQUUkR9qYrw9lM1nAnvR1wOWHLxTnIVag5y6iw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702743654; a=rsa-sha256; cv=none; b=bf0ot1IdZeFonYxG5A6A+Mz3/5o8jbA4SB8BrzcL3PDmSQHUodcH5+rlxCpIOaVUl+zCRB uNq5SFGxgXFq9KuATCiwMBl4hfGy1sfsmdzIGv9cfKR1pTf43BXfDLm7ZkmzB/kaBEogGU RRmL0pE1dmjU4IzXzTsLcdigTb1C8OEOxTqdf1iEPkuRTctwpQa6qe2tcnwYbzJmRShOgG sLYKipqu8Yc159QZCZ0mAZTnlbO2T0IacuEsP1qEL0W+JtWlwOqEy8T8fSbqHVYPlT6BHt ZExeqJx1xya2ukIwlZ8m+XK8RTI6WoGdzYVCWnDnDeTyHgRxMeNOw8J5GbO5yw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702743654; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Ue1hzjEo5vm1I1kA5C3lZK3MZL3dJOb81hjtmp16WtM=; b=kfnJdHk3mkf+O/NANw/vHpq+KhMO9+oLmtV16HsAeR1EtfCQLPCLmXJt9t/BLhpPA12UpC VxVqC7Ny82g7OJaPRF/ALMIIqKOIUE51sDWQGIpjL0rVrHCIJS/N8lrTv5BABju3X1EZW6 YktzzuACFYVhqjncBRl01ideg7MEsM6NQty0LuWB4MpzuF5L4Q9lwSIFxgIF+LLZVegnqF K38NhDP4q+SmX/YtYpVHxLcxQlUfVKWRo/1I3VRZT0Aov9ZUS43Vs9Eage95RGeO0wseb4 xv8RFVuYXzEWNBc/DxNi0T6IEkvWwoBBGf5Y/R1aqf/9ZSDBZAIwRi1ktj5SIQ== Received: from [10.0.1.27] (unislabs.com [80.251.138.245]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: vvd) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SsrtF63tmzml7; Sat, 16 Dec 2023 16:20:53 +0000 (UTC) (envelope-from vvd@freebsd.org) Message-ID: <8163ed16-27f7-41d5-99b2-062585736546@freebsd.org> Date: Sat, 16 Dec 2023 19:20:50 +0300 List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [multimedia/vlc] Re: git: 69e2e87fa56b - main - devel/protobuf: Update to 24.4 Content-Language: ru, en-US To: Po-Chuan Hsieh , multimedia@FreeBSD.org References: <202312141703.3BEH3ta2017850@gitrepo.freebsd.org> Cc: dev-commits-ports-main@FreeBSD.org, ports-committers@FreeBSD.org, dev-commits-ports-all@FreeBSD.org From: Vladimir Druzenko Autocrypt: addr=vvd@freebsd.org; keydata= xjMEZEmcEhYJKwYBBAHaRw8BAQdAzzVRU/u5Oe4kUEFSvaiRoAPwsXMi4uBnfKqFTOIxjaDN I1ZsYWRpbWlyIERydXplbmtvIDx2dmRAZnJlZWJzZC5vcmc+wo8EExYIADcWIQQJVt5Qnq2d fk5hjMKABvqrv5QvcwUCZEmcEgUJBaOagAIbAwQLCQgHBRUICQoLBRYCAwEAAAoJEIAG+qu/ lC9z/qcBALviJppCfpN8fLj5HfnQ75ARS/RvOL+bPHB422uv9PFOAP982mg4uqoYr1BvSVqm rtB7/oxkqReIeieBIkyBTM97As44BGRJnBMSCisGAQQBl1UBBQEBB0D41GJgPsXUyWQckRf7 25z8CsGADMjlIpJbVhWUQLi4fwMBCAfCfgQYFggAJhYhBAlW3lCerZ1+TmGMwoAG+qu/lC9z BQJkSZwTBQkFo5qAAhsMAAoJEIAG+qu/lC9z4bgA/jGNXk0cGGKii1lXk55Gwh2EQhC4pLxQ e/36TZiR29IBAP40fSUJOJ41IS0d8k6d5DQ0E9BJuRf+1S5AzsAUz0rmBQ== In-Reply-To: <202312141703.3BEH3ta2017850@gitrepo.freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------mbNuTkrV80Yg36kcegseuunK" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------mbNuTkrV80Yg36kcegseuunK Content-Type: multipart/mixed; boundary="------------DPkccVn4ZVqCsogoA0Lwe09l"; protected-headers="v1" From: Vladimir Druzenko To: Po-Chuan Hsieh , multimedia@FreeBSD.org Cc: dev-commits-ports-main@FreeBSD.org, ports-committers@FreeBSD.org, dev-commits-ports-all@FreeBSD.org Message-ID: <8163ed16-27f7-41d5-99b2-062585736546@freebsd.org> Subject: [multimedia/vlc] Re: git: 69e2e87fa56b - main - devel/protobuf: Update to 24.4 References: <202312141703.3BEH3ta2017850@gitrepo.freebsd.org> In-Reply-To: <202312141703.3BEH3ta2017850@gitrepo.freebsd.org> --------------DPkccVn4ZVqCsogoA0Lwe09l Content-Type: multipart/mixed; boundary="------------0034016DXTlOs1mwYn9rJaKG" --------------0034016DXTlOs1mwYn9rJaKG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 MTQuMTIuMjAyMyAyMDowMywgUG8tQ2h1YW4gSHNpZWgg0L/QuNGI0LXRgjoNCj4gVGhlIGJy YW5jaCBtYWluIGhhcyBiZWVuIHVwZGF0ZWQgYnkgc3VucG9ldDoNCj4NCj4gVVJMOiBodHRw czovL2NnaXQuRnJlZUJTRC5vcmcvcG9ydHMvY29tbWl0Lz9pZD02OWUyZTg3ZmE1NmI1NGUy Njc0MjliMzI2ZjdmNjE4OGE3YmFhYTcxDQo+DQo+IGNvbW1pdCA2OWUyZTg3ZmE1NmI1NGUy Njc0MjliMzI2ZjdmNjE4OGE3YmFhYTcxDQo+IEF1dGhvcjogICAgIFBvLUNodWFuIEhzaWVo IDxzdW5wb2V0QEZyZWVCU0Qub3JnPg0KPiBBdXRob3JEYXRlOiAyMDIzLTEyLTE0IDE2OjM1 OjMwICswMDAwDQo+IENvbW1pdDogICAgIFBvLUNodWFuIEhzaWVoIDxzdW5wb2V0QEZyZWVC U0Qub3JnPg0KPiBDb21taXREYXRlOiAyMDIzLTEyLTE0IDE3OjAzOjEwICswMDAwDQo+DQo+ ICAgICAgZGV2ZWwvcHJvdG9idWY6IFVwZGF0ZSB0byAyNC40DQo+ICAgICAgDQo+ICAgICAg LSBVc2UgVVNFUz1wYXRoZml4IHRvIGZpeCAucGMgaW5zdGFsbGF0aW9uDQo+ICAgICAgLSBC dW1wIFBPUlRSRVZJU0lPTiBvZiBkZXBlbmRlbnQgcG9ydHMgZm9yIHNobGliIGNoYW5nZQ0K PiAgICAgIA0KPiAgICAgIENoYW5nZXM6ICAgICAgICBodHRwczovL2dpdGh1Yi5jb20vcHJv dG9jb2xidWZmZXJzL3Byb3RvYnVmL3JlbGVhc2VzDQo+IC0tLQ0KPiDigKYNCj4gICBkZXZl bC9wcm90b2J1Zi9NYWtlZmlsZSAgICAgICAgICAgICAgICAgICAgfCAgNDkgKysrKystLS0t DQo+ICAgZGV2ZWwvcHJvdG9idWYvZGlzdGluZm8gICAgICAgICAgICAgICAgICAgIHwgICA2 ICstDQo+ICAgZGV2ZWwvcHJvdG9idWYvZmlsZXMvcGF0Y2gtTWFrZWZpbGUuaW4gICAgIHwg IDExIC0tDQo+ICAgZGV2ZWwvcHJvdG9idWYvZmlsZXMvcGF0Y2gtaTM4NiAgICAgICAgICAg IHwgIDEzIC0tLQ0KPiAgIGRldmVsL3Byb3RvYnVmL2ZpbGVzL3BhdGNoLXNyYy1NYWtlZmls ZS5pbiB8IDEyNCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgZGV2ZWwvcHJvdG9idWYv cGtnLXBsaXN0ICAgICAgICAgICAgICAgICAgIHwgMTY0ICsrKysrKysrKysrKysrKysrKysr KysrKy0tLS0tDQo+IOKApg0KPiAgIG11bHRpbWVkaWEvdmxjL01ha2VmaWxlICAgICAgICAg ICAgICAgICAgICB8ICAgMSArDQo+IOKApg0KPiAgIDcyIGZpbGVzIGNoYW5nZWQsIDIzNCBp bnNlcnRpb25zKCspLCAyNDggZGVsZXRpb25zKC0pDQo+DQo+ICoqKiA0MjYgTElORVMgU0tJ UFBFRCAqKioNCg0KSGkhDQoNCjEzLjItcDggYW1kNjQuDQoNCjEuIG11bHRpbWVkaWEvdmxj IG5lZWQgVVNFX0NYWFNURD0gYysrMTcgZm9yIGJ1aWxkIHdpdGggbm90IGRlZmF1bHQgDQpv cHRpb24gQ0hST01FQ0FTVDoNCg0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIA0KL3Vzci9sb2Nh bC9pbmNsdWRlL2Fic2wvY29udGFpbmVyL2ludGVybmFsL2NvbXByZXNzZWRfdHVwbGUuaDo0 MDoNCi91c3IvbG9jYWwvaW5jbHVkZS9hYnNsL3V0aWxpdHkvdXRpbGl0eS5oOjE2NDoxMjog ZXJyb3I6IG5vIG1lbWJlciBuYW1lZCANCidpbl9wbGFjZV90JyBpbiBuYW1lc3BhY2UgJ3N0 ZCcNCnVzaW5nIHN0ZDo6aW5fcGxhY2VfdDsNCiDCoMKgwqDCoMKgIH5+fn5+Xg0KL3Vzci9s b2NhbC9pbmNsdWRlL2Fic2wvdXRpbGl0eS91dGlsaXR5Lmg6MTY1OjEyOiBlcnJvcjogbm8g bWVtYmVyIG5hbWVkIA0KJ2luX3BsYWNlJyBpbiBuYW1lc3BhY2UgJ3N0ZCcNCnVzaW5nIHN0 ZDo6aW5fcGxhY2U7DQogwqDCoMKgwqDCoCB+fn5+fl4NCi91c3IvbG9jYWwvaW5jbHVkZS9h YnNsL3V0aWxpdHkvdXRpbGl0eS5oOjE4MToxMjogZXJyb3I6IG5vIG1lbWJlciBuYW1lZCAN Cidpbl9wbGFjZV90eXBlJyBpbiBuYW1lc3BhY2UgJ3N0ZCcNCnVzaW5nIHN0ZDo6aW5fcGxh Y2VfdHlwZTsNCiDCoMKgwqDCoMKgIH5+fn5+Xg0KL3Vzci9sb2NhbC9pbmNsdWRlL2Fic2wv dXRpbGl0eS91dGlsaXR5Lmg6MTgyOjEyOiBlcnJvcjogbm8gbWVtYmVyIG5hbWVkIA0KJ2lu X3BsYWNlX3R5cGVfdCcgaW4gbmFtZXNwYWNlICdzdGQnDQp1c2luZyBzdGQ6OmluX3BsYWNl X3R5cGVfdDsNCiDCoMKgwqDCoMKgIH5+fn5+Xg0KL3Vzci9sb2NhbC9pbmNsdWRlL2Fic2wv dXRpbGl0eS91dGlsaXR5Lmg6MTk4OjEyOiBlcnJvcjogbm8gbWVtYmVyIG5hbWVkIA0KJ2lu X3BsYWNlX2luZGV4JyBpbiBuYW1lc3BhY2UgJ3N0ZCcNCnVzaW5nIHN0ZDo6aW5fcGxhY2Vf aW5kZXg7DQogwqDCoMKgwqDCoCB+fn5+fl4NCi91c3IvbG9jYWwvaW5jbHVkZS9hYnNsL3V0 aWxpdHkvdXRpbGl0eS5oOjE5OToxMjogZXJyb3I6IG5vIG1lbWJlciBuYW1lZCANCidpbl9w bGFjZV9pbmRleF90JyBpbiBuYW1lc3BhY2UgJ3N0ZCcNCnVzaW5nIHN0ZDo6aW5fcGxhY2Vf aW5kZXhfdDsNCuKApg0KDQoNCjIuIFdpdGggZGVmYXVsdCBvcHRpb25zIGluIHBvdWRyaWVy ZToNCj09PT0+IFJ1bm5pbmcgUS9BIHRlc3RzIChzdGFnZS1xYSkNCldhcm5pbmc6IHlvdSBt aWdodCBub3QgbmVlZCBMSUJfREVQRU5EUyBvbiBsaWJoYXJmYnV6ei5zbw0KV2FybmluZzog eW91IG1pZ2h0IG5vdCBuZWVkIExJQl9ERVBFTkRTIG9uIGxpYnBuZy5zbw0KV2FybmluZzog eW91IG1pZ2h0IG5vdCBuZWVkIExJQl9ERVBFTkRTIG9uIGxpYnRoZW9yYS5zbw0KV2Fybmlu ZzogeW91IG1pZ2h0IG5vdCBuZWVkIExJQl9ERVBFTkRTIG9uIGxpYnY0bDIuc28NCldhcm5p bmc6IHlvdSBtaWdodCBub3QgbmVlZCBMSUJfREVQRU5EUyBvbiBsaWJ2ZHBhdS5zbw0KDQoN CjMuIE9uIGxpdmUgc3lzdGVtIHdpdGggUVQ1IG9wdGlvbiBhbmQgaW5zdGFsbGVkIHhwbSwg eGluZXJhbWEsIHhleHQgYW5kIA0KZnJlZXR5cGU6DQo9PT0+IENoZWNraW5nIGZvciBpdGVt cyBpbiBTVEFHRURJUiBtaXNzaW5nIGZyb20gcGtnLXBsaXN0DQpFcnJvcjogT3JwaGFuZWQ6 IGJpbi9zdmxjDQpJdCdzIC0tZW5hYmxlLXNraW5zMiBjb25maWd1cmUgb3B0aW9uIC0gZGVm YXVsdCAiYXV0byIuDQoNCg0KbXVsdGltZWRpYUAsIHBhdGNoIGZvciAxIGFuZCAzIGlzIGlu IGF0dGFjaC4gRG8geW91IG5lZWQgcGF0Y2ggZm9yIDI/DQoNCi0tIA0KQmVzdCByZWdhcmRz LA0KVmxhZGltaXIgRHJ1emVua28NCg0K --------------0034016DXTlOs1mwYn9rJaKG Content-Type: text/x-patch; charset=UTF-8; name="vlc_skins_chromecast.diff" Content-Disposition: attachment; filename="vlc_skins_chromecast.diff" Content-Transfer-Encoding: base64 ZGlmZiAtdXIgbXVsdGltZWRpYS92bGMub3JpZy9NYWtlZmlsZSBtdWx0aW1lZGlhL3ZsYy9N YWtlZmlsZQotLS0gbXVsdGltZWRpYS92bGMub3JpZy9NYWtlZmlsZQorKysgbXVsdGltZWRp YS92bGMvTWFrZWZpbGUKQEAgLTMxLDYgKzMxLDcgQEAKIFVTRVM9CQljb21waWxlcjpjKysx Ny1sYW5nIGNwZSBkZXNrdG9wLWZpbGUtdXRpbHMgZWxmY3RsIGdldHRleHQtdG9vbHMgXAog CQlnbWFrZSBnbm9tZSBpY29udjp3Y2hhcl90IGxpYnRvb2wgbG9jYWxiYXNlIHBhdGhmaXgg cGtnY29uZmlnIFwKIAkJdGFyOnh6CitVU0VfQ1hYU1REPQljKysxNwogCiBDUEVfVkVORE9S PQl2aWRlb2xhbgogRUxGX0ZFQVRVUkVTPQkrbm9hc2xyOmJpbi8ubGlicy92bGMgIyBTZWUg UFIgMjcwMDM4CkBAIC03NCw3ICs3NSw3IEBACiAJCUxJVkVNRURJQSBMVUEgTUFEIE1GWCBN T0RQTFVHIE1QRUcyIE1UUCBNVVNFUEFDSyBcCiAJCU5DVVJTRVMgTkZTIE5MUyBOT1RJRlkg T0dHIE9HR1NQT1RTIE9QVElNSVpFRF9DRkxBR1MgT1BVUyBQTkcgUFVMU0VBVURJTyBcCiAJ CVFUNSBSRUFMUlRTUCBSVU5ST09UIFNBTVBMRVJBVEUgU0lEUExBWSBcCi0JCVNETCBTSE9V VENBU1QgU01CIFNORElPIFNUUkVBTSBTUEVFWCBUQUdMSUIgVEhFT1JBIFwKKwkJU0RMIFNI T1VUQ0FTVCBTS0lOUyBTTUIgU05ESU8gU1RSRUFNIFNQRUVYIFRBR0xJQiBUSEVPUkEgXAog CQlUV09MQU1FIFVQTlAgVjRMIFZBQVBJIFZDRCBWRFBBVSBWUFggVk9SQklTIFdBWUxBTkQg WDExIFgyNjQgWDI2NSBaVkJJCiBPUFRJT05TX0RFRklORV9wb3dlcnBjPQlBTFRJVkVDCiBP UFRJT05TX0RFRklORV9wb3dlcnBjNjQ9CUFMVElWRUMKQEAgLTEwNiw2ICsxMDcsNyBAQAog UkVBTFJUU1BfREVTQz0JUmVhbCBSVFNQIGFjY2VzcyBtb2R1bGUKIFJVTlJPT1RfREVTQz0J RW5hYmxlIHJ1bm5pbmcgYXMgcm9vdAogU0lEUExBWV9ERVNDPQlDNjQgc2lkIGRlbXV4IHN1 cHBvcnQKK1NLSU5TX0RFU0M9CUJ1aWxkIHNraW5zMiBpbnRlcmZhY2UgbW9kdWxlCiBTVFJF QU1fREVTQz0Jc3RyZWFtIG91dHB1dAogVEFHTElCX0RFU0M9CUlEMyB0YWcgYW5kIE9nZyBj b21tZW50IHN1cHBvcnQKIFZDRF9ERVNDPQlBdWRpby9WaWRlbyBDRCBzdXBwb3J0CkBAIC0y OTksNiArMzAxLDExIEBACiAKIFNIT1VUQ0FTVF9MSUJfREVQRU5EUz0JbGlic2hvdXQuc286 YXVkaW8vbGlic2hvdXQKIFNIT1VUQ0FTVF9DT05GSUdVUkVfRU5BQkxFPQlzaG91dAorCitT S0lOU19VU0U9CQlYT1JHPXhleHQseGluZXJhbWEseHBtCitTS0lOU19VU0VTPQkJeG9yZwor U0tJTlNfQ09ORklHVVJFX0VOQUJMRT0Jc2tpbnMyCitTS0lOU19JTVBMSUVTPQkJUVQ1CiAK IFNORElPX0xJQl9ERVBFTkRTPQlsaWJzbmRpby5zbzphdWRpby9zbmRpbwogU05ESU9fQ09O RklHVVJFX0VOQUJMRT0Jc25kaW8KZGlmZiAtdXIgbXVsdGltZWRpYS92bGMub3JpZy9wa2ct cGxpc3QgbXVsdGltZWRpYS92bGMvcGtnLXBsaXN0Ci0tLSBtdWx0aW1lZGlhL3ZsYy5vcmln L3BrZy1wbGlzdAorKysgbXVsdGltZWRpYS92bGMvcGtnLXBsaXN0CkBAIC0yLDYgKzIsNyBA QAogJSVOQ1VSU0VTJSViaW4vbnZsYwogJSVRVDUlJWJpbi9xdmxjCiBiaW4vcnZsYworJSVT S0lOUyUlYmluL3N2bGMKIGJpbi92bGMKIGJpbi92bGMtd3JhcHBlcgogaW5jbHVkZS92bGMv ZGVwcmVjYXRlZC5oCg== --------------0034016DXTlOs1mwYn9rJaKG Content-Type: application/pgp-keys; name="OpenPGP_0x8006FAABBF942F73.asc" Content-Disposition: attachment; filename="OpenPGP_0x8006FAABBF942F73.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEZEmcEhYJKwYBBAHaRw8BAQdAzzVRU/u5Oe4kUEFSvaiRoAPwsXMi4uBnfKqF TOIxjaDNI1ZsYWRpbWlyIERydXplbmtvIDx2dmRAZnJlZWJzZC5vcmc+wo8EExYI ADcWIQQJVt5Qnq2dfk5hjMKABvqrv5QvcwUCZEmcEgUJBaOagAIbAwQLCQgHBRUI CQoLBRYCAwEAAAoJEIAG+qu/lC9z/qcBALviJppCfpN8fLj5HfnQ75ARS/RvOL+b PHB422uv9PFOAP982mg4uqoYr1BvSVqmrtB7/oxkqReIeieBIkyBTM97As44BGRJ nBMSCisGAQQBl1UBBQEBB0D41GJgPsXUyWQckRf725z8CsGADMjlIpJbVhWUQLi4 fwMBCAfCfgQYFggAJhYhBAlW3lCerZ1+TmGMwoAG+qu/lC9zBQJkSZwTBQkFo5qA AhsMAAoJEIAG+qu/lC9z4bgA/jGNXk0cGGKii1lXk55Gwh2EQhC4pLxQe/36TZiR 29IBAP40fSUJOJ41IS0d8k6d5DQ0E9BJuRf+1S5AzsAUz0rmBQ=3D=3D =3Dx+2b -----END PGP PUBLIC KEY BLOCK----- --------------0034016DXTlOs1mwYn9rJaKG-- --------------DPkccVn4ZVqCsogoA0Lwe09l-- --------------mbNuTkrV80Yg36kcegseuunK Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQJVt5Qnq2dfk5hjMKABvqrv5QvcwUCZX3OYgUDAAAAAAAKCRCABvqrv5Qvc5RR AQDR+GUCSxGVzR3cHwpYVuxbYXfBUTXAiaTJvotDxih1PgEA8wHh4OjpEC7uc7NlbMakiyTL2/wS 3zSOQc2oxMqwOQU= =tRxG -----END PGP SIGNATURE----- --------------mbNuTkrV80Yg36kcegseuunK-- From nobody Sat Dec 16 17:00:43 2023 X-Original-To: multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SssmZ3VHQz549mY for ; Sat, 16 Dec 2023 17:01:02 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SssmY1d3dz3JwR; Sat, 16 Dec 2023 17:01:01 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=c2zis752; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::112a as permitted sender) smtp.mailfrom=kob6558@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-5e3338663b2so11892007b3.2; Sat, 16 Dec 2023 09:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702746060; x=1703350860; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=jpsoKO8ZvqTXi3mG+4NB2HKHM3R/nt0rJ3o/QtuxGvk=; b=c2zis7524Dl9OJslllkqtsr7jAnTICm9qx9VcvxOcXStfmHt/EFNhguKi+YAsrHBbH Qxuoo5f8fSy4j5LUOowVB1fBDY+f31UCe4Q1PhI/EXzHuCdWxrX5KE4+SWgCA0nNtzFq D+Pt4HTxwDvCQjU7muSfOJX23d71iflZG9V4T1JiH3wzsI1ju//h3rKFbQ80Ml2dGaSw HwU/j5Cb3YHuHF6QKytJmuotwsLQ7fyyI6VAFeNbjeLUrGOHQXYC+I1UsUUeURVcm2CE lo833WVj30O811umCmz3I5OcuVdmrt0N4ZYIc7hpEKm3yMLK9s13awgTXP/XMcYmZlzM XNKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702746060; x=1703350860; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jpsoKO8ZvqTXi3mG+4NB2HKHM3R/nt0rJ3o/QtuxGvk=; b=p3pQvbeS9n1O821P+YqL8MkFPBBmRwASHC5+cg45QGNf7FyEAEUP9pXmBmZs3gvaKQ LFxoxwwk03UtjZ26tts3HLYS7noU4BwJYqRdCdEpWUe/g2uw4llDOrkHvHfn+elnkFih TrHNeHK2NAUPtGcSx4/aff2XN+R8XVJnPBD2CEVYwEYtJukmLt2S8UuNJ/2e8C6tXCWs +hG6eE5hPpDbyxnjV8fOdvFIdCzOgsknnqI6M70zLeI5DmJma/zZfh9bo4LVWU/RTaxM ZGRaqYGYkBWmIVtBPKzrmlpiXNZRVnsVsNEna5cvCG2IOzctY0Gpfjvt7br2pA5DW0Oi 4lyg== X-Gm-Message-State: AOJu0Yxer5eNsd223tZQTKaGU8KBcpwPyViBO00uLFuGk0OaysOBd7ye 1LgnUCtUyEC44o8UMIm3v0ZkJn1ESwoofFVfNfljeqJt X-Google-Smtp-Source: AGHT+IGFot1vetldQqb2uNulsCdufylEk02YwLSkWqXFvL3+iWuFg3GqvV6JYiGotFqWWc8LyjaxgQSb4PKMaiNBK1w= X-Received: by 2002:a81:9e42:0:b0:5d7:1941:aca with SMTP id n2-20020a819e42000000b005d719410acamr10453013ywj.101.1702746059862; Sat, 16 Dec 2023 09:00:59 -0800 (PST) List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 From: Kevin Oberman Date: Sat, 16 Dec 2023 09:00:43 -0800 Message-ID: Subject: Update to x265-3.5 broke many multimedia tools To: multimedia@freebsd.org, mi@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000a74d9060ca3763f" X-Spamd-Result: default: False [-3.61 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.91)[-0.909]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[multimedia@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112a:from]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4SssmY1d3dz3JwR X-Spamd-Bar: --- --0000000000000a74d9060ca3763f Content-Type: text/plain; charset="UTF-8" Yesterday x265 was updated to 3.26 which included a major version change to libavcodec. As a result, ports that use libavcodec are broken. At a minimum, fmpeg, libheif and the avidemux ports all need to have PORTREVISION bumped. I have not checked on other ports which depend on x265, but I have probably missed a few. Ports using ffmpeg and libheif do not need the bump. after reinstalling ffmpeg and libheif, thongs like mpv ae once again working normally. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --0000000000000a74d9060ca3763f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yesterday x265 was updated to 3.26 which include= d a major version change to libavcodec. As a result, ports that use libavco= dec are broken. At a minimum, fmpeg, libheif and the avidemux ports all nee= d to have PORTREVISION bumped.

<= div style=3D"font-family:tahoma,sans-serif;font-size:small" class=3D"gmail_= default">I have not checked on other ports which depend on x265, but I have= probably missed a few. Ports using ffmpeg and libheif do not need the bump= . after reinstalling ffmpeg and libheif, thongs like mpv ae once again work= ing normally.
--
Kevin Oberman, Part time kid herder and retired Network E= ngineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1= 694B318AB39EF1B055683
--0000000000000a74d9060ca3763f--