That is awesome news. I need to find a usb audio device I have somewhere to test.

indeed ! well done Lyle !

does it mean that webcam could potentially work on OS4 ? I remember Corto saying that isochronous was missing in the usb driver and thats why webcam could not work on our machines/system.

That's exactly right.

That's why I included the source code.
A programmer could copy the USB code from USBAudio2, change the search terms to whatever webcams use, and very quickly they would have access to the raw data coming in from a webcam (or other video input device)

I did it already, but then I had no idea what to do with the data. (No, I'm not sure where I put it on my hard drive)

Maybe someone with experience with FFMPEG could shovel the data into there.. or save the stream.. or whatever they choose.

But yes, isochronous transfers are "different" and the code I included is one example of using them.


Here's an odd concern that I realized this morning:
All this is possible because of fairly recent updates to the USB stack for OS4. HOWEVER I'm really not sure how often (or who) is distributing updates to "the public". So, there's a chance that I have released software that will only work on Beta or Developers machines! If this is the case, I don't think I violated any NDA's (I hope) since the code is all mine, but it MIGHT not work at all on a public level system.

Things were so much easier when the updates happened quickly.

Anyway, I am looking forward to messages telling me what devices it works with, as well as hoping to hear that it works for something on a public(non Beta) system.

I know we are good with the Behringer UMC404HD, and probably it's smaller brothers, UMC202HD, UMC22, UM2. I'm most curious about the Scarlett device, and even one of the Blue SnowBall microphones. (Just curious, I don't need a microphone for anything). I'm also sure most older or cheaper devices probably will NOT work, since the Audio2 protocol was released in 2006.

wandering back to your question: Yes, we are ready for webcam software, and the code was released in case someone wants a head start.

Lyle

While I'm here, there's a few details I need to add somewhere:

The software I wrote is for "Audio protocol 2" of the USB standard.
The original audio standard (did you know Audio was the _original_ purpose of USB??) left out some really important things, like how to set the sample rate!

The result is that each manufacturer figured out their own way of setting sample rate. There are at least three different ways to do it, and no documentation for any of them. My favorite of the three is automatic. The chip simply watches incoming data and sets it's speed to the closest matching sample rate. Since it involves no programming, it just works!
Another way is to use the "alternate interface" mechanism of the USB stack to choose different speeds.
Then there are some that do something different completely!


Anyway, The nice people at the USB group eventually decided to rewrite the audio standard, and AUDIO2 was released back in 2006. They added lots of stuff for clock selection and control, timing domains and lots of other cool stuff. Part of the changes included changing many of the descriptors that an audio device uses to describe itself to the machine. As a result, it's really tedious to write a driver that supports Audio1 and Audio2. I had an old Audio1 test program ages ago, but it only worked with self-adjusting adapters. Without documentation, I never figured out the other ways of doing things.

So that's what the whole "Audio2" specific stuff is about.
YES, this code could be adapted to write an "Audio1" program, if you can figure out the undocumented details. I have no patience for figuring out stuff like that.

But beware: you'd have to start by checking every single audio class specific structure, to make it match the old documents instead of the new ones, then working through the sample rate stuff by the "Helen Keller" method.

Another question: AHI Driver?
There's a lot of messy issues.. AHI expects a driver to know all the details in advance, USB discovers them by reading the device descriptors. AHI expects all devices under the same driver to be the same, again, this does not work out well for USB. And on and on..
Can it be done? Sure.
Can it be done well? I don't think so.
Will it ever be done? Sure. Once I release AudioLink.library, it'll be as easy as clicking a gadget to connect them in either direction. But that's another bit of code that's hoping to get off my hard drive one day.

But for me, I've got a good quality 4 channel interface, and I can record and play back at will

Thanks !!! Awesome news!

Recording works with Roland Rubix 24. But trying play back through it locks up X1000 solid. The same as trying to use Rubix' MIDI interface, it locks up the machine.

I made a bug report for the MIDI part some time ago but the USB guy said he will need your help.

I contacted you a couple of years ago to get help to write something like this. It's nice you found time to get this piece of software done and nice the source code is available.

PS. Monitor option or the VU program doesn't show anything.

This is excellent.. or at least half excellent. about the lockups.. ill try to set aside some hobby money for a rubix.. once it's here I should be able to fix both lockups. about the meter not working. if you're up to a bit of troubleshooting: download camdtools from the depot. in a shell: "midiwatch VU". in another shell: "USBAudio2 MONITOR meter VU". play some audio into the rubix. if all is well, you should see a lot of note messages in the midiwatch shell. if you do, then you've confirmed that the data is coming out... and vumeter should default to using VU as a source.. I think. at any time you can type clusterlist into a shell to see which clusters are open at any time. cluster names are case sensitive. Sorry about spelling..punctuation. I'm on an android from bed. time for me to sleep. good luck.

cool stuff thanks Lyle

Hi LyleHaze

First of all, thanks for your efforts.

I have a Behringer UM2. I have a beta system with latest USB-Stack
When I try UM2 with your release

"usbaudio test.raw monitor"

I get "Failed to lock USB Audio Interface"

Am I doing something wrong ?

This is on Sam460..I haven't tried on X5000 or A1222 yet.

I can also test Olympus LS-P2 and DM-5 voice records with USB Composite-Audio class.

Sounds like that interface is using the first audio protocol...
sorry about that, but good to know.

@LyleHaze

This time I used MOOER G200 guitar processor (which I believe it has USB audio built-in)
https://www.mooeraudio.com/product/GE200--48.html

This time I don't get "Failed to lock USB Audio Interface" message, but it seems nothing is happening.

Also I am not able to break or CTRL-c USBAudio2

Really good news.

But it a shame IOSpirit stopped selling software in 2007, they had the VHI studio, for webcams.

http://web.archive.org/web/2007011306 ... https://www.iospirit.com/

It sounds like I have more work to do. it's great that this is finally off my drive and out in the world. yesterday i fixed tooltype handling for proper use as a default tool.. ill make a list as these comments come in and we will proceed as best I can. Thanks to all for the feedback, please keep it coming!

I tested Audio-Technica turntable which has an USB output (besides analog outputs) with verbose mode.

File: ram:blaa
Mode:Record
0 Seconds
0 Channels
at 0 samples per second
using 0 bit samples
RawFkt [NULL]
VULink
MinIor 8
Alternate 1
FillOut = FALSE
Help = FALSE
Verbose = TRUE
openAll() returns succesfully
usbaudio2.c 30: USB direction is Record or Monitor
Using first avalable RawIFC of 0x00000000
Failed to lock USB audio interface

USB Inspector lists 3 USB AUDIO CODEC's under Audio. Two subclass 1's and one subclass 2.

Type: Interface
Product: USB AUDIO CODEC
Vendor: BurrBrown from Texas instruments
Serial no:
Version: 1.0
Class:Audio
Subclass: 2
Drive: none

Testing ancient Logitech webcam. USB Inspector says it's Vendor Specific Interface, subclass 255. Running USBAudio2 prints the same output as with the turntable.

VU meter works actually. I guess I had wrong arguments the last time.

About those VU meters: I've had them open full time for a couple years now, both on the A1222 and the X1000. They are really quite useful. They're also ugly. Just plain rectangles. User can specify height, width, screen position, foreground color, background color, number of channels, and individual ballistics for upward and downward movement (damping). There's even options to display just a smaller section of the full range. Not many people have audio equipment that is audible down to -32 dB. But I'm hoping that releasing the code will help some artistic user to create a better looking meter. One idea would be to show both fast (peak) and slow (average) from the same data stream. this is often done with a dot floating above a bargraph. Another option would be a display that looks like a real VU meter, for the old folks like me. For any of this, the code is public, and all you need is new drawing routines for whatever you create. Because it's built on CAMD, you can have as many meters open as you like. And, for the control freaks in the room, you could have a program monitor the levels and make decisions, like maybe turning down loud commercials, or detecting silence to detect the end of a show.. This gets extra useful if you have a MIDI controlled audio mixer. (Yes, and it can be controlled by GUI/Script/MIDI Playback, but I only made ONE). Or just a prefs window for all the options that the existing meters have. Like many, I learned C programming by modifying someone elses source. IF anyone wants to play with these audio meters, the source is out there. Lyle

"Failed to lock USB interface" is a poor way to say
"I still haven't found what I'm looking for".

In this case it's not an Audio Protocol 2 device.

I'll work on better messages. :)

Lyle

@ LiveForIt

Quote:

Handy for other capture devices too. I tried it out with the vhi driver Elbox made for PCI TV cards.

At the time, I emailed Felix to ask if he'd sell the source code etc for his Amiga software. He said he wasn't considering at that time but may change his mind in the future.

Maybe 16 years later he'd consider selling VHI studio for a reasonable price or possibly open source it.

At least IOSpirit are still around so it's not hard to contact him but are there many others who'd like this software available and possibly updated.

Hi Lyle

Congrats on the progress - it's so cool!

Your concerns about versioning, though, seems to be right. I just checked up on history and, although not tested, here are my findings for latest public release based on module history documents:
- USB stack: Should be working with isochronous transfers.
- EHCI hardware driver: No isochronous support. Latest public EHCI release is the 2018 version which is about half a year before I started looking at it.
- OHCI hardware driver: Back in 2015 somebody implemented experimental isochronous support, and it was left at that. It is based on normal IO requests, which is what the USB stack supported at the time. So I would expect some audio stuttering if usable at all. I only recently acquired an OHCI controller to do some unrelated bug hunting, so haven't tried it.
- UHCI hardware driver: No isochronous support.

And, to set the record straight with regards to isochronous support, only the status for the EHCI driver has changed since then.

Regards,
Thomas

Thank you Thomas. We were hit with a nasty hurricane Wednesday morning, and I am still without power, network, and many other comforts. I'll be back when I can. Lyle

We have power!
We have internet!
My employer is closing!

It's always something.

This will delay my plan to purchase the Roland interface for testing.
Thomas's information reveals that the current USB audio software may be unsuitable until some USB system softwares get updated.. and personally I'm not sure how or when they might get public release.
I've also been told that some other audio software, both my own and others, may soon support VU meters.
My own local copy has already had a few updates, and certainly will get more as time allows.
There was a bug if the named file didn't open for playback.. and the tooltype handling is much improved for using USBAudio2 as a default tool.


Thanks all for your patience and feedback.. we will continue to make progress.

Lyle