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 <hsela...@freebsd.org>
AuthorDate: 2021-09-22 13:42:51 +0000
Commit: Hans Petter Selasky <hsela...@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
_______________________________________________
dev-commits-src-main@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main
To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
