Media-OS: Official Release Thread

Software Proprietary & Other
1

What began as a weekend project to modernize my old BeOS apps under Haiku, became a three-month adventure in trying to make my USB MIDI and Audio devices function properly with Haiku. So, you might be wondering, what is Media-OS? It is not an operating system, nor is it a Haiku distro. It is an AI assisted engineering testbed for rapid development of Audio, Midi, and other drivers and apps for Haiku. Media-OS currently offers packaged replacements for USB drivers, including UHCI, OHCI, EHCI, and XHCI, as well as multi audio, usb_audio, usb_midi, and midi_server.

Version 1.0.3 - First Public Release

  • Adds support for legacy Midiman, Yamaha, and Roland/Edirol midi devices to the usb_midi driver
  • Opens up the usb_audio drivers and multi-audio to support a wide variety of soundcards. Stock Haiku currently limits USB Audio support to USB 1.1 Full-Speed devices that only have one stereo out. Our replacement removes the single stereo out limitation and opens it up to High-Speed USB2 devices, which make up the bulk of prosumer USB Audio devices. UAC1 and UAC2 are supported, and all USB busses are supported, including EHCI.
  • In addition to stability and performance enhancements in Audio and MIDI, there are also changes to the USB stack that could benefit non-Pro Audio users. The biggest being support for Super-Speed USB rates behind USB3 hubs, which currently enumerate as High-Speed devices. Isochronous data communication had changes across all USB drivers, which I hope also proves useful for the various video and cam projects out there. And finally, disconnecting and hot plugging USB MIDI and Audio devices should no longer cause either KDL or system freezes (this may also extend to other USB devices causing issues when plugged in or unplugged).

To Install
# 64-bit pkgman add-repo https://hpkg.indispensablelabs.com/media-os/x86_64/current

# 32-bit (x86_gcc2 hybrid) pkgman add-repo https://hpkg.indispensablelabs.com/media-os/x86_gcc2/current

pkgman install mediaos

The Future:

  • Audio latency is higher than I would like it to be. Getting about 60ms latency from an audio loopback on a DDJ-SR. Very far from the 20ms that I would find useable for serious performance usage. I will be looking into this further, although it is not my drivers per se, as the USB drivers are on par or even outperform the stock HDA drivers on my system, despite the extra USB cost. MIDI latency is very good, just over a millisecond on most busses, although it creeps up to about 2 ms over EHCI.
  • Firewire Storage Drivers and Firewire Audio/MIDI drivers starting with BeBoB and DICE protocols.
  • SCSI Storage Drivers and native SCSI sample dump support
  • Enhanced Patchbay/Midi Device Manager
  • Native VST implementation

You can post bug reports or feature requests to this thread or email indispensablelabs@gmail.com. Do not send bug reports for Media-OS replacements to Haiku. It is not their problem. Banners have been added to the syslog so that you can more easily determine that the modules are Media-OS replacements.

8 Likes
2

I believe your information about the USB Audio driver in Haiku is out of date. The patch for USB2 support was recently merged.

1 Like
3

Regarding the firmware needed for Midiman devices, what the license of these firmwares? Can they be distributed or should the end user have to find on his own how to find where to get this file ?

I guess the same question could concern the M-audio firmwares, right?

2 Likes
4

That would be great news, but it must be in the nightlies and not Beta 6 if that is the case, because Beta 6 was all retested. Regardless, even if it was switched on in nightlies, that would not include numerous other bug and stability fixes for the USB stack as a whole, nor would the developer necessarily have access to the number of testing devices at my disposal, which conveniently cover just about every use case out there.

I won’t say that Haiku efforts on this didn’t have thousands of hours of testing, because I don’t know. I do know that my replacements have had testing in the thousands of hours, and everytime I think I am about ready for release, I uncover another deficiency in the system that needs fixing. It’s kind of like peeling an onion.

Good news is I am not trying to keep any of this to my self and will be working with @phoudoin to try to get as many patches upstreamed through CRs as possible in the coming weeks. We can find a balance between keeping AI code out of Haiku, while still reaping the benefits of our hard work.

2 Likes
5

Yes, the patch for USB2 landed after beta 6. I saw korli and waddlesplash made some other fixes in the USB stack since then as well. No thousands hours of testing yet because this is very new, I probably didn’t spend thousands of hours in front of my computer since I made the fix (that would amount to about two to three months, I think? Probably more as a lot of my time is also spent sitting in front of non-haiku computers or not in front of computers at all).

6

Awesome, glad to know they are back on it. Looks like I will have to start a Nightlies/Beta 7 branch, where I can bring in the upstream changes, and remove any of my own replacements that were covered. Once I can verify the changes made, that should also cut down on the number of CRs I need to prepare in the next couple of weeks.

Right now, the only firmware supported is for legacy Midiman devices. The firmwares packages were part of the MAudio for Linux project that they did with Debian some years back. As such, the packages themselves are freely distributable in their current packaged form. Currently cold Midiman devices are detected by my midi_server replacement, if the devices already have the firmware saved the midi_server loads the file and flashes the device, which then reenumerates in its warm state which midi_server picks up and sets nodes up for. When midi_server detects a cold device and the firmware is not yet available on the user’s machine, it runs a Python script, which prompts the users permission/intention to download the official Linux firmware package. I do not currently store or redistribute the firmware, it all comes from Debian’s servers as they are the official maintainer of it. Now that I have some free time, I will likely contact Debian and see if they would like me to carry the actual package in a repo, as to cut down on their own server load. But for now, it is within the usage of the firmware license and with the extra Python script as an abstraction layer, the downloader never actually touches any of my actual MIT licensed code. This is very similar to how a lot of similar firmware loaders work.
I did stop short of adding some extra Midiman firmware based on the methods of the MacOS Midiman driver project, which requires downloading official MAudio drivers and extracting firmware from the package. That is a legal grey area that I would need to do more research on, as it is modifying and/or obtaining the firmware in a way that most likely violates the license of the driver package. I will look more into it, but probably not until we have some users asking for support for those devices. Back when I believed my only scope was USB MIDI drivers, Claude almost got me in a bit of a mess. We ran into a timing issue with the MidiSport 2x2 and could not get the device warm. While I have been really careful around software licensing, I was not careful enough to have observed that the firmware contained a non-modification clause. So early on Claude offered to patch the firmware for me to get around the timing issue, which it did successfully. But luckily none of this was public at the time, I caught the firmware licensing issue, and now that I carry much more of the Haiku modules, fixing it properly became easy.

2 Likes
7

NOTICE: I really need to clarify, that these packages are for Beta 6. Installing on nightlies will not be packageable as Haiku updates will overwrite many of my packages, and will need to rely on a script install with blocklists to run. Not sure when I will work on that.
For now, I am targeting Beta 6 users, and I will also be bringing in new features from the nightlies into my project, so that Beta 6 users will get them with Media-OS updates.

1 Like
8

The USB2 change actually just removed the gate that prevented USB 2.0+ devices from being recognized. With that and the recent work done on Haiku’s XHCI Isochronous, it opened up some testing opportunities for me to try some of my sound devices that did not work under Beta 6. I was able to get sound out of my Denon DN-HC4500 over XHCI on stock Haiku nightlies.
On the HC4500, 48k works flawlessly. 44.1k and 96k are both glitchy, for different reasons. 44.1k and 88.2k (anything not evenly divisible by 1,000) are glitchy across all devices and all USB hosts. The 96k is particular to my hardware, although it has to affect other devices using Haiku as well. Basically, the device has no feedback endpoint, and it is already at full bandwidth, so I had to do a little extra work to smooth it all out.

The gate on USB 2.0+ was mainly there prevent crashes from EHCI connections. So turning it on also sends anyone trying to use a USB2 port instead of a USB3 port into KDL. It has been disabled this long for a reason. But I say let it KDL, as it gives you guys something to fix. So in Beta 6, USB 2.0 is disabled altogether with the gate. In the nightlies, if the user is running on an XHCI port, they can expect clean 48k, 96k could vary by device, and 44.1k always a bit glitchy. But if the user connects to, or possibly only has USB2 on their device, it is unusable.

I just finished testing the nightlies against my other Denon, a DN-HD2500. Also a USB 2.0 UAC1 device. It only has 44.1k and I assumed it would work with some slight glitches. Instead I got 10 seconds of clean sound followed by terrible digital noise. Basically its the product of both of the first two glitches I described - the 44.1k glitch and the 96k glitch (but in this case it is just that it also has to use every bit of bandwith in the 2ch 44.1k alt it was set to. The two bugs together, and audio totally falls apart.

There is only one other UAC1 device I have that should work with the stock drivers - the Pioneer DDJ-SR, but Haiku doesn’t support 24-bit 3-byte packets. So that is a no. And then you also have UAC2 devices which also still do not work under stock nightlies.

I just happened to own an awesome collection of devices that cover USB 1.1 and 2.0, UAC1 and UAC2, and had some interesting but not uncommon quirks. My dev machine only had Intel USB2 (UHCI/EHCI) ports, so I bought a Renasas XHCI card and found that one of my Belkin combo cards had an NEC OHCI/EHCI chip. So, I have been in a very unique position to figure this all out. So, the thousands of hours indeed were not spent on just lifting the USB 2.0 gate, it was also solving all of the other issues that made the gate necessary in the first place, and a host of other fixes across multiple areas.

1 Like
9

So I guess, and be kind here because while I looked in details in your changes regarding MIDI, I didn’t that much for your usb_audio and USB stack, it could lead to at least 3 tickets with details of each issue, and possibly 3 CR to fix them in haiku codebase :

  • USB audio glitches for anything but 48k
  • add support of 24bits samples in 3 bytes packets
  • the EHCI kdl

?

1 Like
10

There is more than that in that change.

  • the computation of buffer siees was attempting to send buffers according to the microframe size, this makes no sense, it was leading to way too small puffers and was removed. The logic to compute buffer size is the same for usb1 and usb2 now.
  • when testing on my hardware I found that 24 bit (hacked on 3 bytes) audio was broken because the multi audio format converter code doesn’t know how to handle that and was writing 32 bit values. For now I have disabled 24 bit support. It should be re-enapled and the format converter gode should be fixed.
  • there were several other fixes in xhci and ehci in the last gouhle weeks as well.
1 Like
11

Sorry, I have been keeping you waiting. I couldn’t help from checking back in on the recent nightly development, but I am done with that testing now. So let me look into my upstream notes and try to pick the most important areas that people are working on for usb_audio, so we can get those submitted ASAP. MIDI can definitely wait for now, as it is fairly complete minus handling the device quirks. But usb_audio is still very rough in a lot of places. I definitely need to get the CRs done before I dive into latency issues or start Firewire development.

Sorry, I didn’t mean to imply that that was the only change specifically. As I am honoring forum rules, these posts are all my own words. Claude would have maybe told me to tone it down a bit. :rofl: Very excited that y’all are working on it, and I don’t want to diminish your work. I just need to find a way to be more involved in the current development, because it looks like a few of us are actively involved in the same areas, and I am not able to submit PRs, so until I issue a CR, no one even knows I completed the work and passed all of these hurdles. Is there a mailing list I should join?

2 Likes
12

I didn’t wanted to sound pushy or impatient, don’t worry.

I was just trying to see if the changes you found out that were needed to support he’s more high end USB audio devices could be splitted into smaller parts, in hope I could try to ramp up my limited understanding on a more smaller part of the topic so that I could provide some actual help.

I guess joining the haiku-development mailinglist could make sense, indeed.

13

You are good. You are not impatient; it was just me realizing that I was holding things up, and I don’t think you need worry about having a limited understanding of the matter. You have more knowledge than I do on submitting CRs and on what Haiku needs and expects. Since you will likely not be the actual person making the audio changes, I think that puts us in a great position. Our job is to figure out exactly what my findings were in order to prepare the CR. What I learned from my only upstream fix, was the need to fully understand the issue and then explain it plain human terms. Them taking our report and then them implementing on their own terms is exactly we need, and it also adds an abstraction layer, where they write human code without ever seeing our AI assisted code. We just feed them what is wrong and what needs to be changed. I can always A/B between my own version and what Haiku comes up with, and if there are performance or other issues, we can reiiterate from there. My whole goal is for this to all be upstream, and for this project not to have a reason to exist at some point.