From nobody Sat Oct 05 19:52:58 2024 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 4XLbfq1qb7z5XbhP for ; Sat, 05 Oct 2024 19:52:35 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XLbfp6rCQz4Z5G; Sat, 5 Oct 2024 19:52:34 +0000 (UTC) (envelope-from alfix86@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2e0a5088777so2555455a91.2; Sat, 05 Oct 2024 12:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728157953; x=1728762753; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3o/J8bqoK138rwJGTQ8mHe//7pVcSh00EAomvQEuSAM=; b=AJVbPuh0S6py8wAYge0KeraxioHtv4E+RswygQKct24W3a/rfH1WRtW+yKt4crqaPd E6252P/mASCPOpT+wOgqrF9W33rzgjnIWapn5MD2+oc3VzxlJV7d5uujRA5oWqSSF/b5 UJkXxmV5cLhwRoaFyzC9XQVlu2L1dEtZnof0sOCE5oIZ2onZ7hgeXh1wUkUwjmG0sp9e hU2Qe7ip2CUei3JfFgX3Yp9e5TfDKxEeYNjQS0ttTVFywi+3ZPk7pGHuk9axhVNdVhpa 5tJ5nMFmRIcQXDW6MRH/ufcUF3Ea3KNu1LLqvPvrrRNpysy4VYOSMNXkXG1qrR/nYU5z K0NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728157953; x=1728762753; h=cc: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=3o/J8bqoK138rwJGTQ8mHe//7pVcSh00EAomvQEuSAM=; b=NlsdmnxFd4XXB6OXGPy/3/MNl0fYV4lzJ2wYmVS+vB0kjgf+VIPc7qiE0TRPY7nkxX uCNrblCzzLT2fByP9zvVYWeQhvUmu4SPYzVEkHVQmJbJ2Vty2rwB15pVOmlm0ojgTu8a 0uSZkha6NCOPUHfzVHb5cQw9YGUS75CPEGKiaGoVI2MeV58TeBUp4xOuWIhJF/2+NG0J sLKrAnvF7laGfwnEYbZ5KRMe5sdsX+3SWrq1u1//SjkBmofBofeDeqPGnLV+JXVsgSSG 0NE6tqlC+O0/tt1ib4J2b5YyYsxaGZVGsg3KYx2DVBVWkrP2x2miTwg/gX8IToBEB38h ao0A== X-Gm-Message-State: AOJu0YxjGaCg+ysrQ6MPCSyDKWqZ4FVbPSbtu9LjLArhuOpHCUnq53KV aoVjNnU6e1/A0MHaLKDXhQphFJ03TTyF/Mz725jTdhrmoeSVYGVDO0j+QNE3syMTBDIJGPqgjIJ 8C+sj1dMsVSjZQ0xZewYspCmg8c14gNqY X-Google-Smtp-Source: AGHT+IHFZ8r+R1ZK6FjDwrwFe9CwFj7y4xTsEflUuLjeCR7HkDo4nndjt3mDC029HqZhu9yLGVJUKl+GlOhJ7cvS+kI= X-Received: by 2002:a17:90b:17c8:b0:2d3:bc5e:8452 with SMTP id 98e67ed59e1d1-2e1e631e4e8mr7466674a91.32.1728157953282; Sat, 05 Oct 2024 12:52:33 -0700 (PDT) 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: Alfonso Sabato Siciliano Date: Sat, 5 Oct 2024 21:52:58 +0200 Message-ID: Subject: Re: New meaning oss_sysinfo.nummixers To: Christos Margiolis Cc: multimedia@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ebde200623c020b7" 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XLbfp6rCQz4Z5G X-Spamd-Bar: ---- --000000000000ebde200623c020b7 Content-Type: text/plain; charset="UTF-8" Hello, On Sat, 5 Oct 2024 at 20:11, Christos Margiolis wrote: > Hello Alfonso, > > Alfonso Sabato Siciliano wrote: > > I was inactive for months, one week ago I reinstalled CURRENT on my main > > laptop (and others). The meaning of "struct oss_sysinfo.nummixers" > > changed. Let's say: > > > > [...] > > > > Output "nummixers: 7", But > > > > % sysctl dev.pcm > > ... prints 6 devices dev.pcm.[0-5].* > > > > % ls /dev/mixer* > > /dev/mixer0 /dev/mixer1 /dev/mixer2 /dev/mixer3 /dev/mixer4 /dev/mixer5 > > > > 6 mixers from 0 to 5. But now oss_sysinfo.nummixers is 7, it was 6 until > > some months ago. > > > > I thought the new value could be the max index, in the case some mixers > > are closed, example /dev/mixer0 /dev/mixer2 /dev/mixer5. But in this > > case 'nummixers' should be 5 not 7. > > > > Maybe the hidden /dev/mixer is in the count (6 + 1 = 7). > > > > Same situation on 3 laptops. So, what is the new meaning for > > oss_sysinfo.nummixers? > > The behavior changed in the following commit of mine: 5d980fadf73d > ("sound: Handle unavailable devices in various OSS IOCTLs") [1]. > The commit message explains the rationale behind changing this > behavior. I am aware it's a bit quite unintuitive, but it solves quite a > few bugs we have with people using nummixers to loop through mixer > devices, which I suppose is the most typical use. > > Ok, I understood the point of the commit. > oss_sysinfo.nummixers now is simply populated with whatever > devclass_get_maxunit(pcm_devclass) returns, which should be the _next_ > maximum unit number that will be allocated for an audio device, hence > the 7 you get (this is how devclass_get_maxunit() works in general). > > Here is my doubt, (probably) I don't understand "_next_ maximum unit number", in this case my _next_ should be 6 not 7. Same on other 2 laptops. Actually, I was referred to this change because I am receiving several private emails for mixertui, when users run F6 can see a suddenly extra pcm (unreal /dev/mixer). Anyway, now it is not a problem, I am going to handle it in userspace. I'll take a look at devclass_get_maxunit() in the future. Although a bit tedious, you can count the actual number of mixers in the > system by issuing open(2) for each /dev/mixer and seeing which ones > succeed. This way you know the total number, but also which mixers > specifically are present. > > Christos > > [1] > https://cgit.freebsd.org/src/commit/?id=5d980fadf73df64a1e0eda40a93170ed76ce6f14 OK. Best regards, Alfonso --000000000000ebde200623c020b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

On Sat, 5 Oct 2024 at 20:11, Ch= ristos Margiolis <christos@freeb= sd.org> wrote:
Hello Alfonso,

Alfonso Sabato Siciliano wrote:
> I was inactive for months, one week ago I reinstalled CURRENT on my ma= in
> laptop (and others). The meaning of "struct oss_sysinfo.nummixers= "
> changed. Let's say:
>
> [...]
>
> Output "nummixers: 7", But
>
> % sysctl dev.pcm
> ... prints 6 devices dev.pcm.[0-5].*
>
> % ls /dev/mixer*
> /dev/mixer0 /dev/mixer1 /dev/mixer2 /dev/mixer3 /dev/mixer4 /dev/mixer= 5
>
> 6 mixers from 0 to 5. But now oss_sysinfo.nummixers is 7, it was 6 unt= il
> some months ago.
>
> I thought the new value could be the max index, in the case some mixer= s
> are closed, example /dev/mixer0 /dev/mixer2 /dev/mixer5. But in this > case 'nummixers' should be 5 not 7.
>
> Maybe the hidden /dev/mixer is in the count (6 + 1 =3D 7).
>
> Same situation on 3 laptops. So, what is the new meaning for
> oss_sysinfo.nummixers?

The behavior changed in the following commit of mine: 5d980fadf73d
("sound: Handle unavailable devices in various OSS IOCTLs") [1].<= br> The commit message explains the rationale behind changing this
behavior. I am aware it's a bit quite unintuitive, but it solves quite = a
few bugs we have with people using nummixers to loop through mixer
devices, which I suppose is the most typical use.


Ok, I understood the point of the comm= it.
=C2=A0
oss_sysinfo.nummixers now is simply populated with whatever
devclass_get_maxunit(pcm_devclass) returns, which should be the _next_
maximum unit number that will be allocated for an audio device, hence
the 7 you get (this is how devclass_get_maxunit() works in general).


Here is my doubt, (probably) I don'= ;t understand "_next_ maximum unit
number", in this case my _n= ext_ should be 6 not 7. Same on other 2 laptops.
Actually, I was referre= d to this change because I am receiving several
private emails for mixer= tui, when users run F6 can see a suddenly
extra pcm (unreal /dev/mixer&l= t;n+1>).
=C2=A0
Anyway, now it is not a problem, I a= m going to handle it in userspace.
I'll take a look at devclass_get_= maxunit() in the future.

Although a bit tedious, you can count the actual number of mixers in the system by issuing open(2) for each /dev/mixer<n> and seeing which one= s
succeed. This way you know the total number, but also which mixers
specifically are present.

Christos

[1] https://cgit.f= reebsd.org/src/commit/?id=3D5d980fadf73df64a1e0eda40a93170ed76ce6f14


OK.

B= est regards,
Alfonso

=C2=A0
<= /div> --000000000000ebde200623c020b7--