Opened 12 years ago

Last modified 3 years ago

#1045 assigned enhancement

USB isochronous streams

Reported by: wkornewald Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/USB Version: R1/pre-alpha1
Keywords: Cc: doug@…, siarzhuk, emitrax, mmlr
Blocked By: Blocking: #10521, #11256
Has a Patch: no Platform: All

Description

Our USB stack needs to support isochronous streams.

Change History (22)

comment:1 Changed 12 years ago by wkornewald

Type: bugenhancement

comment:2 Changed 12 years ago by tigerdog

Cc: doug@… added

comment:3 Changed 12 years ago by siarzhuk

Cc: siarzhuk added

comment:4 Changed 11 years ago by korli

Cc: emitrax added

Shouldn't this be reassigned to emitrax ?

comment:5 Changed 11 years ago by emitrax

The stack itself now has isochronous support, I'd split it into two different enhancement tickets, one for UHCI (which has not-well-tested support) and one for EHCI. What do you think?

comment:6 Changed 11 years ago by mmlr

I'd leave it like this. It serves as a reminder and I think we can keep track of the three points it combines.

comment:7 Changed 6 years ago by siarzhuk

Cc: mmlr added
Owner: changed from mmlr to siarzhuk
Status: newassigned

I have temporarily taken ownership of this to let all know that I'm working ATM on implementation and testing isochronous support for OHCI controllers.

comment:8 in reply to:  7 ; Changed 6 years ago by modeenf

Replying to siarzhuk:

I have temporarily taken ownership of this to let all know that I'm working ATM on implementation and testing isochronous support for OHCI controllers.

Nice. Still working on this?

comment:9 in reply to:  8 Changed 6 years ago by siarzhuk

Replying to modeenf:

Nice. Still working on this?

Yes. Hunting for problems and trying to bring the usb_audio to life. http://siarzhuk.dyndns.org/cgit/haiku.zz/log/?h=isochronous

comment:10 Changed 6 years ago by modeenf

Nice.. I will save that link ;)

If I have understode isochronous. Isochronous are needed for streamin over USB. Then Bluetooth and usb webcam need's it?

comment:11 in reply to:  10 Changed 6 years ago by siarzhuk

Replying to modeenf:

Nice.. I will save that link ;)

If I have understode isochronous. Isochronous are needed for streamin over USB. Then Bluetooth and usb webcam need's it?

It depend on the nature of transferred data. Isochronous is intended for time-critical faults-tolerant data streams. Typical samples of such data are audio or video streams that can lost some part of frames repeatedly without affecting on subjective data consistency. AFAIK Bluetooth provides very wide set of data transfer models. Some of those models can be faults-tolerant (audio-data) some will require data safety.

You can use the listusb -v to get info about your bluetooth device - in case there are some isochronous endpoints listed - you will need this support form the stack.

comment:12 Changed 5 years ago by siarzhuk

Good news: OHCI has isochronous support starting from hrev45972. Unfortunately both UHCI and EHCI implementations need to be redesigned to be triggered by HC's interrupts instead of using additional isochronous transfers finishing thread that eats 100% of CPU. Additionaly EHCI HCD implementation uses so agressive locking algorithm so TransferCallback cannot be used to submit the next isochronous transfer because of corresponding double lock panic. I hope to look into UHCI implementation in the nearest future.

comment:13 Changed 5 years ago by modeenf

Blocking: 9933 added

comment:14 Changed 5 years ago by korli

Blocking: 9933 removed

(In #9933) I removed the relation with UVC and isochronous streams as these devices use a vendor specific bulk-only interface.

comment:15 Changed 5 years ago by siarzhuk

Blocking: 10521 added

(In #10521) 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.

comment:16 Changed 4 years ago by anevilyak

Blocking: 11256 added

(In #11256) As those two tickets already address everything mentioned in this one, there's no reason for it to exist.

comment:17 Changed 4 years ago by danboid

The main and only real OS/driver level issue that prevents me switching to Haiku from Linux is that I cannot use my USB audio devices (such as the Focusrire Scarlett 18i20 and 2i4) via EHCI.

I have a few questions for siarzhuk I hope he's kind enough to answer:

  • Will the Haiku USB audio driver get enabled when we have isochronous streams working under EHCI or will we have to wait for XHCI to work too before that happens? The latter would seem silly to me. Is there even such a thing as a USB 3 only audio device?
  • Does the Haiku USB audio driver support audio input, unlike OSS? Should it be able to recognise and use all 8 XLR inputs on my 18i20? Both my Focusrite devices are USB class-compliant and work great under ALSA/Linux.
  • Is there any support for S/PDIF IO in the USB audio driver yet?

Thanks!

Last edited 4 years ago by danboid (previous) (diff)

comment:18 in reply to:  17 Changed 4 years ago by siarzhuk

Replying to danboid:

  • Will the Haiku USB audio driver get enabled when we have isochronous streams working under EHCI or will we have to wait for XHCI to work too before that happens? The latter would seem silly to me.

As already described somewhere in comments above - the reason not including usb_audio in the image - the behaviour is just dangerous on systems with incomplete isochronous transfers support (EHCI, UHCI) - system locks up or goes to KDLs. But on OHCI controllers it has worked for me well. So there are no special requirements for XHCI support for including usb_audio as soon as UHCI and EHCI will be finished.

Is there even such a thing as a USB 3 only audio device?

No idea about current state - but besides of existence of USB Audio 2.0 specifications for many years - most of hardware still produced with USB Audio 1.0 specs. IMO we have another decade before USB Audio 3.0 specs will be written and such hardware will be produced. :-) usb_audio was designed to support both specification 1 and specification 2. But the usb audio 2 devices support was obviously not tested.

  • Does the Haiku USB audio driver support audio input, unlike OSS? Should it be able to recognise and use all 8 XLR inputs on my 18i20? Both my Focusrite devices are USB class-compliant and work great under ALSA/Linux.

AFAIR, as soon as those inputs are published by device in standard USB Audio compliant descriptors they will be available for driver - and, hopefully, for user too.

  • Is there any support for S/PDIF IO in the USB audio driver yet?

AFAIR it depends on support of such input type in Media Kit. At the moment of active usb_audio development very basic set of input types was available and supported by Media Kit.

comment:19 Changed 4 years ago by danboid

Thanks for your quick reply siarzhuk!

It seems I misunderstood the state of the USB audio support so I need to slightly rephrase one of my questions.

Presuming that EHCI and UHCI are separate code entities that aren't going to be solved in one hit somehow, could we see USB audio support enabled in Haiku if isochronous works for EHCI but not UHCI? UHCI and OHCI are rare on machines from the last decade or so which mostly have EHCI and/or XHCI. Could we not just disabe USB audio if UHCI is detected if that was the case?

Sounding promising!

comment:20 Changed 4 years ago by danboid

Have you tested audio input under OHCI?

comment:21 in reply to:  19 Changed 4 years ago by siarzhuk

Replying to danboid:

Presuming that EHCI and UHCI are separate code entities that aren't going to be solved in one hit somehow, could we see USB audio support enabled in Haiku if isochronous works for EHCI but not UHCI? UHCI and OHCI are rare on machines from the last decade or so which mostly have EHCI and/or XHCI.

To work with USB 1.0 hardware (that is most of USB audio devices until now, BTW) USB 2.0 controller should have either companion USB 1.0 controllers (OHCI or UHCI) to delegate them functions or more complicate hardware. The companions solution, AFAIR, was very popular until USB 3.0 has seen the light. So most of PCs with USB 2.0 should have either OHCI or UHCI controllers onboard too.

Could we not just disabe USB audio if UHCI is detected if that was the case?

Regardless if this is controlled by OHCI, UHCI or EHCI the driver works with generalized intefraces and have no info about the flavour of USB controller. "Dirty hack" solutions have no chances to pass through our strict Code Quality Control Check. ;-)

Replying to danboid:

Have you tested audio input under OHCI?

#9951 is about it. ;-)

comment:22 Changed 3 years ago by siarzhuk

Owner: changed from siarzhuk to nobody
Note: See TracTickets for help on using tickets.