From owner-freebsd-emulation@freebsd.org Sun Oct 6 13:34:23 2019 Return-Path: Delivered-To: freebsd-emulation@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DAAD5FCF0C for ; Sun, 6 Oct 2019 13:34:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46mPjC5YbVz4KwC for ; Sun, 6 Oct 2019 13:34:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BEB2CFCF0B; Sun, 6 Oct 2019 13:34:23 +0000 (UTC) Delivered-To: emulation@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BE7B5FCF0A for ; Sun, 6 Oct 2019 13:34:23 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46mPjC4bQgz4KwB for ; Sun, 6 Oct 2019 13:34:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8238426ED3 for ; Sun, 6 Oct 2019 13:34:23 +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 x96DYNZo030332 for ; Sun, 6 Oct 2019 13:34:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x96DYNLX030331 for emulation@FreeBSD.org; Sun, 6 Oct 2019 13:34:23 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: emulation@FreeBSD.org Subject: [Bug 240043] audio/linux-c7-alsa: how to make it work? Date: Sun, 06 Oct 2019 13:34:19 +0000 X-Bugzilla-Reason: AssignedTo CC 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: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: tijl@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: emulation@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 MIME-Version: 1.0 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 13:34:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240043 --- Comment #63 from Tijl Coosemans --- I had second thoughts about the patch. There are fewer thread priority lev= els on FreeBSD than on Linux so the patch maps one FreeBSD priority level to multiple Linux priority levels. With the patch it's possible for a Linux thread to have a higher priority than another thread while the FreeBSD kern= el treats them as if they had the same level. That's a problem for SCHED_FIFO threads because they just keep running until they are preempted by higher priority threads. The current behaviour where FreeBSD announces fewer prio= rity levels via sched_get_priority_(min|max) is correct. A POSIX compliant prog= ram is supposed to use priority levels from this range. FMOD blindly uses prio= rity levels that happen to work on current versions of Linux. Another solution will have to be found. Either the preload trick or maybe libfmod.so could be edited using something like "sed -i.bak 's,libasound\.so,/nonexistent,g' /path/to/libfmod.so"? --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=