enable usb_audio in nightly builds

[tidux]

I have successfully built, booted, and run a @nightly-anyboot gcc2h target with the USB Audio driver enabled. It works with a C-Media Electronics, Inc. Audio Adapter (USB ID 0d8c:000c), and produces sound (although not the right sounds) with a Turtle Beach Amigo II (USB UD: 10f5:0211). Other than hotplug and compatibility fixes for specific models like the Amigo II, the driver is ready to use, and the remaining bugs will be found much more easily with a wider user base to test them. On a more personal note, the USB audio devices are much simpler to use than the nightmarish complexities of getting my Conexant HDA chipset into working with Haiku.

Attached is a patch to enable USB Audio.

[siarzhuk]

Thanks for feedback. You just lucky owner of the OHCI USB controller. Haiku has correct implementation of isochronous transfers for it. UHCI, EHCI and XHCI need to be refactored as described in #1045. Using usb_audio with such controller types crashes the system. That's why it is not in the image yet.

[pulkomandy]

Marked patch as obsolete, so it does not show in the "pending review" list. We will remember to do this when isochronous transfers are implemented well enough to not crash the system too much.

[pulkomandy]

Using usb_audio with such controller types crashes the system.

I think this is not true anymore. So maybe we could enable this driver? Even if it's not working perfectly, as long as it doesn't crash, we can have it in the nightlies and let people test it on a wider variety of devices?

[kim1963]

I have the opportunity to test the driver on three different devices: one device is built into the motherboard of the minicomputer, two external devices. I need a driver’s binary file and testing instructions. I hope to help from the developers of the operating system. https://dev.haiku-os.org/ticket/18320 https://dev.haiku-os.org/attachment/ticket/18320/screenshot127.png https://dev.haiku-os.org/attachment/ticket/18320/screenshot119.png

[waddlesplash]

The driver causes extremely frequent stuttering, if it even works at all. Additionally, due to #12776 and #12777, hot-plugging new audio outputs and switching to them requires *two* media_server restarts done in just the right way, so it's very easy to not even manage to get anything sent to the driver at all, and think it's more broken than it actually is.

Thus, I don't think it should be added to the nightlies until some of those issues are resolved.

[X512]

Well, usb_audio driver is some kind of working and nightly images are intended for testing so why not include it?

[waddlesplash]

Because "testing" only makes sense when problems are not known or not understood. In this case, the problems are known, easily reproduced, and enough to preclude actual usage of the driver; further, users may be confused about which of the 3 issues in question are being triggered when using it. So, we should not enable it, because at this time, no further "testing" is needed; instead someone who understands or wants to try to understand the driver and the media system needs to take the time to fix it.

[kim1963]

​https://cloud.mail.ru/public/y8cE/KFik3jUjn

[nephele]

please don't paste links to random share sites, they may go down. instead copy the text or add it as an attachment.

In this case however I don't see what your text has to do with this issue

[pulkomandy]

It's an example of one of the devices that may be supported by the usb_audio driver. There is no way to know if it will work or not until the driver is enabled.

I will have a test on my machine (my docking station has USB audio) and if the driver doesn't make the system unstable and manage to at least output silence when no one tries to play sound, I will add it to the nightly image.

[kim1963]

Replying to pulkomandy:

It's an example of one of the devices that may be supported by the usb_audio driver. There is no way to know if it will work or not until the driver is enabled.

I will have a test on my machine (my docking station has USB audio) and if the driver doesn't make the system unstable and manage to at least output silence when no one tries to play sound, I will add it to the nightly image.

ОК

[kim1963]

Replying to pulkomandy:

It's an example of one of the devices that may be supported by the usb_audio driver. There is no way to know if it will work or not until the driver is enabled.

I will have a test on my machine (my docking station has USB audio) and if the driver doesn't make the system unstable and manage to at least output silence when no one tries to play sound, I will add it to the nightly image.

??

[pulkomandy]

It does not work on my hardware, see #18497. The high CPU usage and syslog spam means it may not be such a good idea to enable the driver by default yet, until that is solved.

[waddlesplash]

After more XHCI fixes, the driver seems to work and doesn't appear to cause CPU usage spikes here. I will test it a bit more and then enable it on the nightlies.

[waddlesplash]

Enabled in hrev57560.