Page MenuHomeFreeBSD

beep(1): Use AFMT_FLOAT
Needs ReviewPublic

Authored by christos on Sat, Nov 16, 6:18 PM.
Tags
None
Referenced Files
F102926599: D47639.diff
Mon, Nov 18, 8:19 PM
F102859646: D47639.id146596.diff
Mon, Nov 18, 2:37 AM
F102855067: D47639.id.diff
Mon, Nov 18, 1:09 AM
F102847016: D47639.id.diff
Sun, Nov 17, 10:43 PM
Unknown Object (File)
Sun, Nov 17, 7:40 PM
Unknown Object (File)
Sun, Nov 17, 7:06 PM
Unknown Object (File)
Sun, Nov 17, 7:04 PM
Unknown Object (File)
Sun, Nov 17, 5:14 PM
Subscribers

Details

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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 60633
Build 57517: arc lint + arc unit

Event Timeline

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

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.

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.

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.