The Mac-mini is dying to be a media centre. Unfortunately, it's native sound output is limited to 2-channel analogue output.

The only upgrade option is via the addition of USB hardware, however USB audio hardware requires isochronous transfer mode, which is currently unsupported by our driver.

This bounty is for the writing of a USB host controller driver to support isochronous transfers, such as to allow correct functioning of USB audio hardware when attached to a USB port of the ?PD720101 EHCI host controller under MorphOS. The driver should also support all currently supported modes of the existing ?PD720101 driver for MorphOS.

This NEC chip is also used on cheap PCI expansion cards, and in some later MDD Powermac models, so the driver would not be limited in scope to the mac-mini.

PS - I'm not sure the best 'bounty system' to use - if anyone has a preference, or good/bad experiences, please suggest.

I'll start off by committing $50 to the (so-far hypothetical) pot.

[ Edited by boot_wb on 2010/8/3 16:55 ]

Agree, also useful for webcams...

> This NEC chip is also used on cheap PCI expansion cards, and in
> some later MDD Powermac models, so the driver would not be limited
> in scope to the mac-mini.

Is it really chip specific? I was under the impression that the EHCI protocol abstracts from the actual USB host controller chip internals so once that requested feature is implemented it would (or at least should) work with every EHCI compliant USB host controller.

@Andreas
Quote:

To be quite honest Andreas, I have no idea. I have, however, found a couple of patches from NEC for the generic Linux EHCI driver which implement isochronous- and bulk- transfers respectively for this particular chip.

I don't know if just the control- and interrupt- transfer modes are the only generic part of the driver, or if these are workarounds for 'features' which are particular to this chip (ie bugs, or non-conformancies with the EHCI spec).

[ Edited by boot_wb on 2010/8/3 16:55 ]

@Andreas_Wolf:

I'm still unable to find a conclusive answer, however Chris Hodges' answer to a related question strongly suggests that it is work on the drivers that remains to be done (here - final post):
Quote:
If this transfer mode were hardware agnostic, then I would expect implementation of isochronous transfers in Poseidon under OS3.x on the Deneb to have been a read-over into MorphOS (in fact I believe Deneb worked fine under MorphOS for PowerUp, although am unaware if audio hardware remained working).

The chip-specific linux patches I referred to are here, however it's unclear (to me at least) whether these are to enable full-speed isochronous/bulk modes, or simply to improve error handling/correct problems in these modes under certain conditions.

Either way, I suppose I'm suggesting the same bounty: to encourage the work required to implement USB isochronous transfer modes under MorphOS (as a minimum on the mac-mini if it does transpire that the work required is chip-specific).

[ Edited by boot_wb on 2010/8/3 16:56 ]

Quote:

Excellent research boot_wb. By the way, your signature tells you have the beefiest Amiga 4000 I've seen in ages...

Quote:
Just the beginning: I'm afraid I'm barely scratching the surface here.
Given that I know nothing about driver development (and next to nothing about USB outside userland until yesterday), I take it as a compliment on my ability to structure sentences to inspire confidence in what is said. (Translation: sounds good even if I don't know what the hell I'm talking about! )
Quote:
Thanks! It took many years to put together, and now stands proudly in the back of my wardrobe, taking up approximately 50x the volume of my mac-mini
I've been meaning to re-house it at some point to put in a 90 degree zorro adapter, and connect the Prometheus in the last zorro slot (thus allowing access to the PCI slots without reducing the number of zorro slots available), but it's at the bottom of a (very, very) long list of hardware projects.

Back to the matter in hand:

This introduction to USB differentiates between the HCD layer driver and the USBD layer.
Although I haven't got the foggiest idea how Poseidon has been developed, I'd expect the two layers are implemented seperately, with USBD layer being identical (for these purposes) between OS3.x and MorphOS.

Consequently it seems likely that the HCD layer is that which requires more work. This fits with Chris Hodges description above ("Low-level driver work"), fits with the existence of host-controller specific software/patches, and would explain why only Deneb has isochronous transfers implemented (different host controller).

If I may ask, who in the devteam has taken ownership of the USB stack since Chris Hodges left? I'm sure I've asked before at some point, but cannot remember where/when...

[ Edited by boot_wb on 2010/8/3 16:38 ]

ISO-Transfer is just a separate mode of data transfer like Bulk and Interupt transfers are.

Beside the other three protocols ISO transfer doesn't care about data loss. This means if data gets corupted or lost during transfer, no resend takes place to get acurate data. Its just gone. Thats why its used for video/audio transfer, where you simply get a frame drop, which nobody cares about.

The ISO transfer is controller specific, but all controlers use UHCI, OHCI and EHCI, so it would require to add the protocol to all three types of controllers to have full iso support for all devices on all systems.

AFAIR the daneb is using some embedded chip for usb, so it has nothing to do with the drivers MorphOS/Poseidon would need. AROS would be a source for proper drivers, too.

I have no clue about the current drivers, but I know I skipped the iso back at the times of AmithlonUSB as there were no stable application for testing the protocol.

Geit

[ Edited by geit on 2010/8/3 18:37 ]

@Geit

Thanks for the info, and the confirmation.

If the documentation is available, and it's just a matter of man-hours, I'd be happy to put the work in myself. Having not written device drivers previously it would be somewhat challenging, however if no-one is currently working on this I could not possibly be any slower than that (besides, I learn best when I 'need' to, not when I simply 'want' to)

Also, I currently have mucho time on my hands....