Begasus

Thanks a lot for your contribution! Hope you can stick around a bit longer to do follow ups here.

BlueSky

Thanks for your contribution to Haiku and for the detailed report that was very interesting to read.

Starcrasher

Thanks! Beside improving user experience in VM, as a good part of upcoming sound drivers will probably use hmulti_audio, I’d say that your guide itself is priceless.

marcoapc

You create documentation based on your findings, could you explain what is missing in the documentation and unclear points?

1 reply

diegoroux

Hi, @marcoapc.

While working on this driver, I can truly say to you, that a lot of time went into understanding hmulti_audio.

If you try to search of any documentation of multi_audio, you’ll likely come across (although even trying to find this back took me a little while) this mail thread: “[…] I’m afraid no spec documentation is available, reading the sources might help. […]” and a link to an old newsletter.

The “complete” documentation for the driver API is included in three files: multi_audio.h, multi_audio.gb, and multi_audio.txt . To get these files, write to trinity [at] be [dot] com

Only multi_audio.h remains, the others are sadly lost to time.

While the newsletter gives a bit of information about BUFFER_EXCHANGE, it only serves at that. Everything else, shall be inferred from previous drivers and multi_audio code.

Some structs, contain members of which I thought to be important and even defining for what other members should be read, are completely ignored. (See flags in BUFFER_EXCHANGE, playback_latency, record_latency, etc.)

While reading multi_audio.h helped a lot, if you only keep that, you’d never know that B_MULTI_GET_ENABLED_CHANNELS and B_MULTI_SET_ENABLED_CHANNELS are actually required to be implemented; multi_audio.h only warns about B_MULTI_SET_GLOBAL_FORMAT as required to be implemented.

Many little cases like the above exist.

But I think I went a bit long. I hope I cleared it up!

3 replies