[05.14.2009]
vSound
In the summer of 2005, after having completed the vCOM
Virtual Serial Port Driver, I decided to investigate writing a Virtual
Sound Card driver (vSound) for use with Flex Radio's PowerSDR software.
There was a commercial virtual sound card driver available
called VAC, it was relatively inexpensive, but there were various
performance issues when used with PowerSDR. I knew this would
be considerably harder than writing vCOM because the Windows sound
system was largely undocumented by Microsoft.
As with all the open source projects I was working on at the time I had
a "donate" button on my web page. I did not advertise this
and I received a few donations to vCOM development in 2005 and no
donations to vSound in 2005. By early 2006 I had put in a
huge number of hours in developing vSound and was making some progress.
I needed to set up a debug system where I could test the
driver without caring about "blue screens" and I needed to purchase
some driver debug and development software so I could more easily probe
around in the largely undocumented Windows sound system. I
put a note on my web page, after receiving email inquiries as to the
status of vSound, that if the donations to vSound reached $500
(basically a bounty) I would again start development. That
was my estimate of the cost of the software I needed to continue.
Up to this point there had been no donations to vSound.
In June of 2006, Tim Ellison (an employee of Flex Radio) posted a
message to the Flex Radio mailing list that people should contribute to
the vSound development. I received 27 donations in total.
The donations averaged about $30 each for a total of about
$850.00. One guy donated $500, but this donation has been
returned. Unfortunately, many of the people who donated did
not understand that donating to a volunteer open source project does
not offer any guarantee of a finished product - it does not guarantee
that the effort would be successful at all. Many people
looked on it as that they were pre-purchasing a product to be delivered
to them. I never represented the vSound project as that, but it
was my fault that I did not have the foresight to make this clear early
on.
I was able to purchase the software and various items for the
debug system and restart development of vSound because of the
donations. The $850 development fund was depleted at this point.
I found that within a few months after these donations, I now had
20+
"managers" wanting updates on the status of the vSound project -
sometimes weekly. I decided to remove all of the donate
buttons from the website.
Developing a driver project like this is very different from developing
user mode application software such as PowerSDR or SDRMAX.
The user mode software has very little chance of damaging a
user's system if they install it and there is a bug. This is
not the case with drivers. A bug in a driver can cause the
system to crash (the "blue screen"), and there is a potential for data
corruption or loss on the user's system. With vCOM there was
more confidence in allowing people to test beta versions of the driver
since IO port drivers in Windows is much better documented - you have a
better idea of what you can and cannot do to crash the system.
Even with this, during the development cycle of vCOM, users
reported "blue screens" regularly (and sometimes in an irate manner!)
and so I did not want to repeat this experience with vSound.
With vSound, I had to probe and prod the Windows kernel in ways I was
100% sure would cause a system crash. On my debug system, I
must have generated 100 blue screens a day when working out what you
can and cannot do. The Windows sound system is largely
undocumented with poorly written driver examples for Microsoft (some of
which violates their own esoteric rules for Windows sound drivers).
I think you must have to pay $2000 to attend a Microsoft
"school" of writing sound drivers or something to get the "secrets"
that they do not tell you in the documentation! The beta
software release cycle did not happen with vSound for the above reasons
and this added to the displeasure of the donators.
Unfortunately, no matter how many times you tell someone that
software is unstable or can harm their system, there will always be
people who install it anyhow - and then BOOM!.
By the end of 2006, I had put many hours in on the development of
vSound (to the exclusion of anything else) and I had made some very
good progress. A sound card's ADC and DAC are driven by a
hardware clock on the sound card. This generates an accurate
and precise timing reference to generate the sound card sampling rates.
A hardware sound card generates a hardware interrupt that the
sound card driver uses to alert the Windows kernel that data is ready
to be received or sent. In a virtual sound card, there is no
hardware and no hardware clock or interrupt to generate this timing
signal. What virtual drivers like VAC do is to simulate the
hardware clock with a Windows kernel timer which is neither
particularly accurate or precise. Windows is not a realtime
operating system, so a kernel software timer has considerable variation
in when it times out and this depends on system load. This is
what was causing issues with the commercial VAC driver. One
way to get around it is to buffer the data heavily from the virtual
sound card driver to smooth out the variations in the timing of the
software timer. Unfortunately, increasing the buffering
increases the latency of the virtual sound card - a big problem for CW
operation. With vSound I theorized and, after a lot of
probing and poking at the Windows kernel, I found a way that I could
hook into a real hardware sound card's hardware timer interrupt and
route it to the vSound driver to act as the timing reference.
With this I did not have to use a software timer like VAC
does and the problems with doing that would be gone. Since
the vSound driver was being developed for use with Flex Radio's
PowerSDR and sound card based SDR-1000, there would always be a real
sound card in the system that could be hooked into by the vSound driver
so that the hardware sound card and virtual sound card would be locked
together in timing with an accurate and precise timing reference.
With this, the latency could be made very low and there would
be no need for excessive buffering or resampling to make the real and
virtual cards work together without pops, crackles, or stutters.
Information about the new Windows Vista new sound subsystem began to
come out on the driver developers forum. This detoured me for
quite some time in figuring out the differences between XP and the new
Vista way of doing things. Eventually I worked out how to
make the driver work on both operating systems. This change
in the way that Windows handles sound drivers is one of the reasons
what the popular Rocky SDR software does not work on Vista.
At this point in the development cycle I had spent countless
hours. I had to slow down on vSound development because
other more productive things were being neglected.
Flex Radio then began to promote the use of a firewire based sound card
for use with the SDR-1000. This threw a huge money wrench in
the works! My method of hooking into the hardware sound
card's interrupt had worked with all tested PCI sound cards, and most USB
based sound cards. It was not possible to make it work with
firewire based sound cards because of the major differences in how
firewire drivers work. On top of that, Flex then announced
the Flex-5000 which was also firewire based. At this point I
had to make a decision. I could restart development of a
driver that would work with both XP and Vista, and in the case of a PCI
or USB sound card, use the hardware interrupt "hooking" trick but then
resort to using a software timer on firewire sound card systems (like
VAC does regardless of what other, or any other, sound cards are in the
system). So when used with a firewire system, the vSound
driver would be no better than the commercially available VAC selling
for $30. To continue development I would have to invest in a
$280 Ederol FA66 Firewire Audio Interface (the one Flex was
recommending for use with the SDR-1000) as well as considerably more
personal development time. I decided to abandon development
indefinitely because I could not justify in my mind that the end result
of this development effort would be worth it. This is why the vSound driver research and development was shelved.