beep(1): Use AFMT_FLOAT

[christos]

Summary

AFMT_FLOAT is supported by sound(4) as of FILLME, so use it here, since
the whole program works with floats already.

Sponsored by: The FreeBSD Foundation
MFC after: 2 days

[emaste]

I'd suggest we not do this, at least not before quantifying the performance impact of float support (see comment in D47638).

[christos]

In D47639#1086236, @emaste wrote:

I'd suggest we not do this, at least not before quantifying the performance impact of float support (see comment in D47638).

I think it might be better to go through with this change to have it behind us. After all, this is a small program that users normally run once, or at least a few times, so the performance overhead shouldn't be noticeable in the first place - at least wasn't when I tested this.

[emaste]

The reason this program exists is to provide a console beep (^G) in the absence of a PC speaker (with a bit more plumbing). At the end of the day even for that use performance isn't really going to matter -- but also the docs recommend against using AFMT_FLOAT.

I can see that this is useful for testing the kernel support, though.

[christos]

In D47639#1086741, @emaste wrote:

The reason this program exists is to provide a console beep (^G) in the absence of a PC speaker (with a bit more plumbing). At the end of the day even for that use performance isn't really going to matter -- but also the docs recommend against using AFMT_FLOAT.

I can see that this is useful for testing the kernel support, though.

I am aware that they do advise against using AFMT_FLOAT, however the whole program does everything in AFMT_FLOAT, so it seems quite counter-intuitive to me that we convert to AFMT_S32_LE just before the write(2), when we now have support for AFMT_FLOAT.

[dev_submerge.ch]

In D47639#1086742, @christos wrote:

In D47639#1086741, @emaste wrote:

The reason this program exists is to provide a console beep (^G) in the absence of a PC speaker (with a bit more plumbing). At the end of the day even for that use performance isn't really going to matter -- but also the docs recommend against using AFMT_FLOAT.

I can see that this is useful for testing the kernel support, though.

I am aware that they do advise against using AFMT_FLOAT, however the whole program does everything in AFMT_FLOAT, so it seems quite counter-intuitive to me that we convert to AFMT_S32_LE just before the write(2), when we now have support for AFMT_FLOAT.

I concur with Christos here. If we decide to support AFMT_FLOAT in D47638, I don't see any good reason not to use it. The docs recommend against using AFMT_FLOAT with OSSv4, not in general. And we already differ from OSSv4 in the AFMT_ department, substantially.

[christos]

D47638 will be updated, but I think this one should be good to go (not going to commit yet).