A sound idea?

[watlers_world]

It is very encouraging to see that my Sabrent AU-MMSA has lasted longer than my 3D-Sound did.
Do you think that it would be possible to use two USB audio devices concurrently?
Using UHCI, how many 16-bit 44/48khz devices can I use at once?

I have this docking station:
Kensington Technology Group
Model:K33239
Serial:B0607004006

Although the casing is broken, it still seems to work.

Inside I read:
board:DU296ON1
VER: 1.0

I can see two NEC chips. (0409:0059)
NEC Japan
0720112GK;



I alose see these:

CM106-L;

ZT21eLEEA 0542 B5706079T;

PL2305H;

PL2303HX;

ASIX
AX88772LF
0547 USB
D23FU-010;


My Sabrent is a 0D8C:0014;
The CM106-L on the dock is a 0D8C:0006;

Should this USB audio device work with my old code?
For some reason the sound device appears to lock up and return blank information.

[Bret]

I'm not exactly sure what you're trying to do here, but will try to answer the questions I think you're trying to ask.

There currently are no DOS USB sound drivers at all, from anybody anywhere (at least as far as I know). Unless you're running DOS inside some kind of Virtual Machine (underneath Windows or Unix), you won't be able to use USB sound hardware. I do have plans to add USB sound to DOS someday, but it will be a long time before I get around to it.

Regarding whether or not you could use more than one sound system at the same time in DOS, I don't think so. You're only allowed to use one "regular" audio card at a time (e.g., a single SoundBlaster) so you would only be allowed to use one USB audio device at a time also. In theory you could do more than one, but the interfaces are designed assuming there is only one. Even in Windows you are only allowed to use one audio device at a time even if you have more than one installed.

[watlers_world]

Independent USB devices for disparate virtual machines sounds like a neat idea.
Were you thinking of using separate devices for different types of virtualized sound devices?
How many USB sound devices can you connect before encountering bandwidth and latency limits

At the moment, I'm using a Dell Latitude d610.
Since the D610 will only start windows 3.1 in Standard Mode, virtual machines are not an option for my 16-bit windows drivers.
However, DOS applications might still be able to make use of EMM386 and your TSR.

I was using your drivers and my win16 program trying to have a look at at the CM106-L within my K33239.
Unlike my Sabrent AU-MMSA, the Kensington docking station's CM106-L does not reliably return information after the first few requests.
Any clue what might cause its functionality to waver?

Most of my code remains within win16.
http://turkeys4me.byethost4.com/index.htm

[Bret]

For my DOS purposes, I was thinking of creating a virtual SoundBlaster device of some sort using a USB audio device. USB has a standard for audio devices, and fortunately everybody seems to follow the standard. So a "generic" audio driver could at least theoretically be written that should work with most USB audio devices. But, even though there's a standard, it is actually very complicated so even writing a generic driver is pretty involved. Emulating the SB device is also pretty complicated, and I would only attempt to emulate one device (most likely an SB16 or an AdLib since they were very popular DOS sound devices).

I don't know what would happen if you tried to work with a virtualized sound device from Windows. The virtualization requires leveraging capabilities of EMM386, and when you run WIndows in Enhanced Mode it tells EMM386 to change into a "Windows Mode" (through an interface called GEMMIS) and I don't think the DOS sound card virtualizations will work any more once Windows starts. For what you're trying to do, it seems like you would need to access the USB sound device through the BIOS-level interface provided by USBUHCI.

As far as how many USB sound devices you could use at the same time, I really have no idea. My current driver only works with USB v 1 which has a bus speed of only 12 Mbps (a lot of which is "overhead") and streaming audio uses quite a bit of bandwidth. You could certainly have more than one USB audio device hooked up, but I'm not sure if you could use more than one at a time and still have it work well.

I have no idea why the Sabrent stops working -- I've never really messed with sound devices much at all. That of course will change when I get around to writing USB audio drivers.

[watlers_world]

I know nothing of sound blaster hardware.
What is a BIOS-level interface?

It seems that the devices inside the docking station hub are not working properly all the time.
Frequently the devices do not detect and I get an error beep.
I tested the docking station on a Pentium D945 desktop and still found some problems.

It would seem that the devices on this docking station/hub are not the best.
Looks like I need to find a sound device that is more sound in nature.

Does connecting high bandwidth devices to separate UHCI controller indexes provide more than 12mb?

Thanks for the help, Bret.

[Bret]

What is a BIOS-level interface?

A BIOS-level interface can also be called a software interface, and is usually provided as an Interrupt call. For example, you can interact with the keyboard with various INT 16h calls, which is the BIOS-level interface for the keyboard. You can also interact with the keyboard at the hardware level (through the I/O ports and the hardware interrupts or IRQ's). There are advantages and disadvantages to both methods, but from a compatibility perspective using a BIOS (software) level interface is almost always better.

The BIOS (Basic Input Output System) was developed by the early computer manufacturers as a way to insulate programmers (and Operating Systems) from all the intricacies of the hardware and just provide a standard software-level interface that everyone could use. Using the keyboard as an example again, the very first PC's made by IBM had 88 keys on the keyboard and later versions had 101 or 102 keys. If you interface with the keyboard at the BIOS level, you don't need to know what kind of keyboard you actually have (except in certain rare circumstances). If you interface with the keyboard at the hardware level, you do need to know since the keyboards don't work the same way. Another big area for this was in hard drives where there are many different types of hardware (MFM, RLL, ESDI, IDE, SATA, SCSI, etc.). The hardware/BIOS manufacturers provide a standard software level interface (for hard drives it is INT 13h) so that you (usually) don't need to know what kind of hard drive you actually have. You just issue the INT 13h calls and the BIOS does all the "translating" that's needed to interact with the hardware.

Unfortunately, not all types of hardware had BIOS-level interfaces. Sound cards fall into that category. Every sound card manufacturer did things differently, and nobody ever developed a standard software-level interface for sound devices. You always interface with sound hardware at the hardware level. SoundBlaster kind of became the de facto standard for sound cards in DOS, and most DOS applications that use sound will interface with SoundBlaster. Even then, though, SB had different interfaces (e.g., SB and SB Pro and SB 16 all work a little different than each other). The whole issue of Sound in DOS is still a quagmire with no "universal" solution available.

In modern operating systems (like Windows), they don't use BIOS interfaces at all. Instead of the Operating System interfacing with the BIOS which interfaces with the hardware, the new OS's have what amounts to an internal, proprietary BIOS. In Windows, e.g., this is called the HAL (Hardware Abstraction Layer). So, instead of a "universal BIOS" that the hardware manufacturers could use, there are now "proprietary BIOS's" that are unique to each Operating System. Hardware manufacturers now need to write different drivers for each Operating System (and even different version of the same Operating System), and generally speaking they only spend time writing drivers for Windows. And again, what they are writing the drivers to do is interface with the equivalent of a BIOS-level interface inside Windows instead of a "universal BIOS" that can be used by all Operating Systems.

There are newer BIOS "standards", like EFI and UEFI, that are supposed to try and address these shortcomings, but they really don't. EFI and UEFI don't actually provide interfaces that actually "do useful stuff" like the old BIOS's did (in the form of Interrupt calls). What they do instead is provide a form of pseudo-code that describes how you can write your own driver. The idea is for the Operating System to read the psuedo-code from the BIOS and essentially write its own BIOS code in "real time" after the machine has booted. It's really a very weird concept, and also VERY complicated and takes a lot of resources (especially memory) to implement.

Does connecting high bandwidth devices to separate UHCI controller indexes provide more than 12mb?

Yes, each UHCI controller has its own 12 MB of bandwidth that it doesn't share with anybody else. All the devices on the same USB bus (controlled by a single controller) will share the 12 MB, though.

[watlers_world]

I've always heard the word BIOS used for the system BIOS-ROM.
I've never really heard anyone call software interrupt hooks "BIOS functions".
I think the reason is because you can hook interrupts for the sole purpose of software functions.

I thought software hooks were inside the CPU and not within the system BIOS.
Are they actually in a different piece of hardware?

When hardware hooks its own interrupts, any further hardware access that it performs is transparent to the caller.
I've heard the that software within hardware called "Firmware".
Do you plan to place your code within a piece of hardware such as the BIOS-ROM?

I'll have to find a different sound device.
Thanks for the help and advice.

If the USB controller is a USB 2.0 controller will each of it's UHCI have a separate 12mb?

[Bret]

I've always heard the word BIOS used for the system BIOS-ROM.
I've never really heard anyone call software interrupt hooks "BIOS functions".
I think the reason is because you can hook interrupts for the sole purpose of software functions.

The BIOS is in ROM (or something like an EPROM or EEPROM), but as the computer boots it is loaded into RAM. The same thing happens with your Operating System and other applications, though they are stored on a hard drive or floppy instead of ROM. As your computer boots, things get extracted from the disks and ROMs and stored in RAM. That's why even though in DOS you start out with 640k of conventional memory, after you boot you have somewhat less than 640k. Part of what is stored there is the software associated with the BIOS and DOS interrupts.

The way it originally worked was that the first 32 interrupts (0-1Fh) were reserved for BIOS and hardware/CPU functions (e.g., INT 0 is issued when the CPU detects a divide-by-zero error). Interrupts 20h-FFh were allowed to be used by the Operating system. E.g., the main DOS interrupt is 21h. Also, as things progressed, things got a little fuzzier. E.g., the original PC only had 8 hardware interrupts (IRQ's 0-7) which were assigned to software Interrupts 08-0Fh. In the later computers, they added 8 more hardware interrupts (8-15) which were assigned to software interrupts 70-77h. The processing of the hardware interrupts (IRQ's) is considered a low-level (hardware/BIOS) function, not an OS function, even though half of the IRQ's are processed with software interrupts above 1Fh. You can blame that on a lack of planning from Intel and IBM.

Also, just so you know, the difference between a hardware interrupt (IRQ) and a software interrupt (INT) is simply in what causes it to occur. An IRQ is initiated by a piece of hardware inside the computer (like a key being pressed or released on the keyboard or a clock counting down to zero), while a software interrupt is initiated (usually) by an INT call from software. What happens when the interrupt is generated is stored in RAM in both cases, so you can modify or look at what happens when the IRQ or INT is generated. E.g., you can modify what happens when you press or release a key on the keyboard by modifying the software code of INT 09, which is called whenever a key is pressed or released. You can also call INT 09 directly from software if you want, but that is not a good idea. Part of the software code associated with IRQ's (like INT 09) interacts with the hardware that initiated the IRQ (the keyboard), so if you call INT 09 from software the INT 09 code will try to interact with the keyboard when the keyboard isn't expecting anything to happen and you can end up with a big mess (this will often cause crashes).

Do you plan to place your code within a piece of hardware such as the BIOS-ROM?

No, that would make what my programs do part of the BIOS (which is stored in ROM). In my opinion, what my USB programs do should be included in modern computer BIOS's, but that is never going to happen. I consider what the programs do to be essentially a BIOS-level function (theoretically could by used by any Operating System), which is why I chose INT 14h as the interface for the functions (INT 14h is the BIOS Serial interrupt and USB is a Serial Bus).

If the USB controller is a USB 2.0 controller will each of it's UHCI have a separate 12mb?

Sort of. The USB 2.0 (EHCI) controller controls the entire (480 Mbps bus). The EHCI controller only handles the USB 2.0 (high-speed) devices attached to the bus, though. To handle the low-speed (1.5 Mbps) and full-speed (12 Mbps) devices, the EHCI controller passes control to another device. In older USB 2.0 hardware, this was done through UHCI or OHCI companion controllers. When a device was plugged in to the bus, the device is queried to see what its maximum speed is, and if it's high-speed the EHCI controller manages the device and if it's not high-speed the EHCI controller passes control to the UHCI or OHCI controller. Each companion controller manages its own 12 Mbps bus, but the busses all share the same 480 Mbps provided by the EHCI controller. In EHCI, each 12 Mbps bus is "managed" by a separate USB 1.0 controller but it is not really a separate bus like it is when you don't have USB 2.0.

In more modern implementations, they have gotten rid of the companion controllers and just use a Hub that can handle all three speeds. So, instead of an EHCI controller and several UHCI or OHCI controllers, you just have an EHCI controller and a Hub.