Past issues: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=157050 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184380 In the wild some software from ports that have OSS support just define AFMT_FLOAT inside own code. AFMT_FLOAT used in wine: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264973 Currently as workaround wine builds with ALSA. I suggest to add some in kernel conversion from AFMT_FLOAT to some thing that aleady support by "PCM subsystem mixing through its feeder subsystem" or update feeder subsystem to support AFMT_FLOAT.
^Triage: I don't see a proposed solution yet, so "In Progress" may be premature.
(In reply to Mark Linimon from comment #1) I am working on it.
https://reviews.freebsd.org/D47638
Thanks! Probably you can avoid fpu_kern_**() staff. https://stackoverflow.com/questions/10212892/how-to-avoid-fpu-when-given-float-numbers https://www.jhauser.us/arithmetic/SoftFloat.html https://stackoverflow.com/questions/78619/what-is-the-fastest-way-to-convert-float-to-int-on-x86 https://stackoverflow.com/questions/68258170/fastest-way-to-convert-a-float-to-int-in-c https://medium.com/@ryan_forrester_/c-float-to-int-conversion-how-to-guide-aea5be6d3d4b
http://0x80.pl/articles/convert-float-to-integer.html https://onestepcode.com/float-to-int-c/
(In reply to Ivan Rozhuk from comment #4) Note that we need not plain float->int but rather (float*constant)->int; this could be done with integer instructions but either way this should be something we look at after profiling if the overhead of fpu_kern_enter/_leave is excessive.
(In reply to Ed Maste from comment #6) (float*constant)->int -> float->(int*constant) ? :) As described in http://0x80.pl/articles/convert-float-to-integer.html float to int conversion should be not so expensive as fpu_kern_**() staff. Also their code simple and under BSD2 license.
v = ((uint32_t)v & 0x000000ff) << 24 | (v & 0x0000ff00) << 8 | (v & 0x00ff0000) << 16 | (v & 0xff000000) << 24; bswap_32(), htonl() can do same. Also this code look as err since 2 components move to 24 bits.
(In reply to Ivan Rozhuk from comment #8) I did some rewriting before posting and missed this shifting error I accidentally introduced. I updated the diff. Thank you for pointing this out! As for bswap32(), it will cast the in32_t value to uint32_t, which could produce a wrong value if the int32_t sample has a negative value. Or am I missing something?
(In reply to Christos Margiolis from comment #9) After some further research, it seems that bswap32() should not be a problem.