Thanks to share your thinking, but I’m not sure the hundred of people reading
this mailing list can be considered as a platform to push advertisement;
Considering the fact that this mailing list is a kind of museum of questions
without useful or operational reply.
To propose an operational alternative remains a valid reply. And if you know
another one, I invite you to also propose it to Mr Smith… who could lose
several years of his life on a boring subject otherwise.
For your information, we also made a Virtual Audio Cable with the SYSVAD in 2018
The result is for the moment only in this article:
https://www.facebook.com/notes/vb-audio-software/does-microsoft-care-about-audio/2061956880540508
We are also still pointing problems related to WIN10 update and audio driver
re-installation procedure (in different post of this mailing list)
Last subject is from 30 DEC 2019:
https://www.freelists.org/post/wdmaudiodev/Typical-audio-problem-with-WIN10-update,1
Today this WIN10 update problem is representing 99% of our online support…
maybe Microsoft will fix this one day…
Regards
Vincent Burel
De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de Johannes Freyberger
Envoyé : mardi 3 novembre 2020 08:31
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] AW: Re: Virtual Audio Passthrough Driver - data format
conversion?
Hi,
I think we shouldn’t abuse this platform for pushing and advertising our own
products as this platform is purely focused on windows audio driver
development. And there are probably also a lot of other apps out there which do
a similar job.
Best,
Johannes
Von: wdmaudiodev-bounce@xxxxxxxxxxxxx Im Auftrag von Vincent Burel (VB-Audio)
Gesendet: Dienstag, 3. November 2020 06:16
An: wdmaudiodev@xxxxxxxxxxxxx
Betreff: [wdmaudiodev] Re: Virtual Audio Passthrough Driver - data format
conversion?
Hello,
This is basically what you can do with Voicemeeter, right now.
Developing a Virtual Audio Driver working as Virtual Audio Cable and possible
Virtual Audio I/O might require several years of work & validation.
Some days only if using the Voicemeeter Audio API:
https://forum.vb-audio.com/viewtopic.php?f=8 ;
<https://forum.vb-audio.com/viewtopic.php?f=8&t=346> &t=346
Regards
Vincent Burel
De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de wdmaudiodev@xxxxxxxxxxxxxx
Envoyé : lundi 19 octobre 2020 17:55
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Virtual Audio Passthrough Driver - data format conversion?
Hi everyone,
Tim Roberts over at the osr.com forum has been very kind in answering my audio
driver questions over the last few months. Recently, he referred me to this
mailing list where "all the cool audio driver kids, including several very
helpful members of the Microsoft audio team, hang out".
My goal is to play networked voice data (in our app) to a virtual render
endpoint, and have it 'loop-back' to a virtual capture endpoint that 3rd-party
chat apps like Skype, Zoom, etc. can consume.
My audio driver prototype is based on SYSVAD/WaveRT. Besides being newer and
recommended in the docs, WaveRT handles more of the copying data to/from the
DMA buffers. My hope was that I could write less code and have a more stable
driver.
What's needed is just a straight-through audio pipe, so I tried using a single,
common buffer for render & capture streams; keeping the respective
PlayPositions in sync. For this to have a hope of working, both render and
capture streams would have to be identical in terms of format (e.g. channels,
frames/sec). Alas, when I tested, each stream had significant differences in
their PCM format (channels, frame rate). I'm still testing to see if I can
limit/coerce both endpoints to the same format: a single channel at some
arbitrary 'good enough' frame rate, but this approach is starting to look
uncomfortably fragile.
My second prototype is based upon MSVAD/WaveCyclic. With WaveCyclic, I
implement the DMA buffer copying logic, so I can do whatever data conversion is
required. I'm aware of a few other 'virtual audio driver' projects on Github
with similar goals; all based upon WaveCyclic.
I wanted to see how they dealt with the data format conversion issue, but when
I look at their CopyTo and CopyFrom implementations, I don't see them dealing
with conversion at all. There doesn't appear to be any code (e.g. in
DataRangeIntersection) that limits streams to a specific number of channels or
frame-rate.
Can anyone shed light on this?
I'm sure my expectations must be off somehow, but it seems to me that some kind
of conversion must be required when copying data between streams of
sufficiently different format...
