On 03/02/2016 16:11, gareth wrote:
Having been, before retirement, a professional real-time softy, I have kept
computers
out of the shack, not wishing to have a busman's holiday.

Now, I'm prepared to make the change, but in the true spirit of _REAL_
amateur radio to do everything myself.

My question is, what sound card drivers are used for the PC end of the
various softrock, SDRs, etc?

Is it via a .NET component, or perhaps the age-old DirectX approach?

Your question is a little vague so I have have tried to cover all
interpretations.

I am assuming here that you are only referring to windows PCs as there
are windows only libraries. The simple answer is however the
manufacturer writes the driver, given the sheer number of sound cards
out there and the vast number of SDR devices then there is no single
approach to drivers. Most I have come across are written in C or C++ or
some other fully compilable language as opposed to a bytecode compilable
framework such as .net or java - although I do like Java it is a
nightmare if you want to address the hardware directly. Java prefers
that you address an abstraction layer rather than the hardware. Very
occasionally I have seen drivers written in machine code especially
where efficiency, timing and speed is paramount. Machine code coders can
command a very high price for their black magic coding.

As an ex professional softy I am sure that you realise that DirectX is
not a driver, it is a library of APIs for handling graphical and sound
transactions even when you get down to the low-level sound interaction
such as Directsound ultimately Directsound is an interface between the
user software and the sound/graphics card driver. Given the market
demand, most driver writers that want a wide uptake of their products
will create standard interface hooks for the common A/V libraries such
as .net or directX but as for specifics you would be more precise in
your question.

I have written drivers in C and C++ mostly for linux but also windows
where standard drivers were not available. It is a daunting prospect at
first but USB control is actually quite straightforward in most cases.

In a nutshell the process is:
Enumerate the USB devices (in linux this is as simple as a console
command "lsusb").
Locate the USB device usually by manufacturer and type ID.
Interrogate the configuration to find how many interfaces, endpoints and
types (direction of data flow)
Enumerate the interface(s)
Claim the interface(s)
Enumerate the endpoint(s)
Open a communication pipe for synchronous or asynchronous communication
And/or set up events for an interrupt driven comms or use Control comms

Then you have a mass of data that you need to parse and data mine. That
is a difficult bit. I have written a driver for a TV dongle but once I
had the data I was lost. Processing of the data is a lot more specialist
art that I could handle.

In linux it is a little easier to write and install a driver, windows is
a little more restrictive and some flavours on set ups of windows demand
certificates before installation

I am currently writing USB drivers for a Playstation Buzz controller to
turn a raspberry pi into a 16 buzzer quiz machine (complete with QI
style silly buzzer noises). These drivers are being written in python
utilizing the pyUSB libraries. The data transferred in this case is,
thankfully, little more than 6 bytes that needs simple bitwise masking
to find out which button(s) has been pressed. I can just about handle 6
bytes.

Hope that helps

AndyW