git: 903873ce1560 - main - Implement and use new mixer(3) library for FreeBSD.

[Hans Petter Selasky]

Hi Mateusz,

On 10/4/21 10:48 AM, Mateusz Piotrowski wrote:
> Hi Hans,
> 
> On 03/10/2021 21:08, Hans Petter Selasky wrote:
>> On 10/3/21 6:03 PM, Mateusz Piotrowski wrote:
>>> On 22/09/2021 20:03, Hans Petter Selasky wrote:
>>>> The branch main has been updated by hselasky:
>>>>
>>>> URL: 
>>>> https://cgit.FreeBSD.org/src/commit/?id=903873ce15600fc02a0ea42cbf888cff232b411d 
>>>>
>>>>
>>>> commit 903873ce15600fc02a0ea42cbf888cff232b411d
>>>> Author:     Hans Petter Selasky <hselasky at FreeBSD.org>
>>>> AuthorDate: 2021-09-22 13:42:51 +0000
>>>> Commit:     Hans Petter Selasky <hselasky at FreeBSD.org>
>>>> CommitDate: 2021-09-22 17:43:56 +0000
>>>>
>>>>      Implement and use new mixer(3) library for FreeBSD.
>>>>      Wiki article: 
>>>> https://wiki.freebsd.org/SummerOfCode2021Projects/SoundMixerImprovements 
>>>>
>>>>      This project was part of Google Summer of Code 2021.
>>>
>>> This may be a bit late to discuss but the new mixer has a completely 
>>> different
>>> set of options and command-line arguments. In addition to that,
>>> the output of the command is different.
>>>
>>> Shouldn't we keep supporting the previous way of interacting with mixer?
>>> I know that people are scripting mixer and its output in production
>>> in order to control soundcards. Are there any good reasons to keep 
>>> the new
>>> mixer(8) as it is now while keeping the old name? Perhaps we could 
>>> change
>>> the name of the new mixer to, e.g., newmixer. Users are going to have to
>>> rewrite their scripts for mixer(8) anyway for 14.0.
>>>
>>
>> It depends what level of compatibility you need.
>>
>> If you have a script parsing mixer output, then it needs to be binary 
>> compatible so to speak. That means some new features like "mute" won't 
>> work.
> Hmm, I agree that mute and volume controls in the new CLI interface are 
> very consistent. However, in case of the old CLI interface, the mute 
> functionality could also be added without a problem (at least by looking 
> at the manual pages, the "mute" command could look like this: "mixer 
> mute vol"). My point is that I feel that the CLI interface should be 
> backwards-compatible in this case.
>>
>> Would it help to make a port, like "oldmixer", under "audio" ?
> 
> That's a good idea. I've committed the "old" mixer to the ports tree: 
> https://cgit.freebsd.org/ports/commit/?id=e9a0efe4509b8dbdef0b4e4b5b94abf0aebd78a9. 
> 
> 
> However, I feel that it is a solution to a problem that could have been 
> avoided. The mixer improvements should have been introduced in a way 
> that users do not have to do anything to keep their scripts working. At 
> the moment, it does not really matter if a user has to install an 
> additional port or patch their scripts. In the end, it's extra work and 
> potential bugs.

I agree we should avoid breakage. On the other hand only having one API 
to use is better for the long run. Look at USB for example. We support 
multiple different USB APIs. Plain file descriptor based ugen, USB FS 
IOCTLs, libusb v0.1, libusb v1.0 and BSD's libusb v2.0. It makes 
everyone happy at least :-)

Similarly there has been new evdev APIs for X.org and Wayland, and 
having to choose among old and new APIs is confusing for the end-user.

With regards to mixer(8) it looks like we now have a maintainer, 
Christos. Feel free to correct me if I'm wrong.

> On the other hand, from what I understand so far, mixer(8) needed a 
> redesign. Also, usually people don't script mixer(8) too heavily so the 
> changes in the interface are going to be only a minor annoyance when 
> FreeBSD 14.0 is released. An entry in the release notes and the 
> availability of the old mixer in the ports tree should be enough.
> 

Thanks for making that port. I've now updated the notes in UPDATING to 
mention it:

https://cgit.freebsd.org/src/commit/?id=8bc5971be1ece76284b2cdb0addf051afc14044a

--HPS