Technically you could render two different strings at the same time, if using different frequencies!

Manual page itself LGTM, but I would make it use Unicode (or whichever encoding) units, not bytes. With bytes, LSB-first breaks down in the presence of UTF-8, for instance (and all the 1 bits in the first byte would only make it worse). Consider, for instance, beep -t "Ψωμί! Παιδειά! Και όχι επαιτειά!"

Would it work if the intermediate format was UTF-8, but all characters would be output as 16-bit unicode?

Beware that Unicode itself can go beyond 16-bit. I think the kernel supports 21-bit unicode, so should we print everything like 21 bits?

Any opinions?

In D35772#811718, @hselasky wrote:

Would it work if the intermediate format was UTF-8, but all characters would be output as 16-bit unicode?

I'm not sure, but leaning toward "no" because there are enough scripts in common use in the SMP (Hanifi Rohingya comes to mind), SIP (CJK), and TIP (CJK) to require 2 UTF16 codepoints very often.

Beware that Unicode itself can go beyond 16-bit. I think the kernel supports 21-bit unicode, so should we print everything like 21 bits?

21 bits? Oh right, plane 16. Hmm. Maybe stop (or start, depending on output order) at the most significant nonzero byte of the UCS4 codepoint? That's probably lossy, but I'm not sure it matters except for airgap-bridging use cases.

It was 22-bits max for UTF-8 to unicode conversion.

In D35772#811784, @hselasky wrote:

Can you test this updated patch, now with full UTF-8 support.

No bare metal to run 14 on, but if it would work in a VirtualBox VM, I can try in a few days.

Please test!

I am interested to take/continue this feature. Are others already working?

In D35772#943182, @asiciliano wrote:

I am interested to take/continue this feature. Are others already working?

I think no one has worked on this still, so feel free to take this. You can add me as a reviewer if you want.