Andrew87
A lot of people are using asio4all and I think it would be a lot smoother to directly implement support for DirectKS within VirtualDJ, doing away with the extra overhead and tweaking requirement of installing such a driver. A lot of people report better stability with asio4all and better sound quality when compared to their manufacturers actual asio/wdm drivers. In the case of the manufacturers asio drivers being worse, that's probably just bad development of the asio driver - e.g. the Hercules Mk2 console.
However, the fact that people are having better success with asio4all simply shows that on some setups, a cards wdm driver is far superior to its asio driver. The way VirtualDJ operates with wdm drivers at the moment is to run it through kMixer which adds at least 30ms latency to the output and of course suffers from sound quality degradation as kMixer only works in 48khz so it is always resampling. This isn't good for users using their integrated 4.1 and above soundcards. Especially those running a console for control but using their onboard sound.
If I've understood this properly, asio4all provides a wrapper for the wdm driver - its not a real asio driver, but it does run the card using DirectKS which bypasses kMixer, giving the controlling application exclusive access to the card, lower latency and resampling control. If VirtualDJ was able to do this itself then it would free up some resources on the system which could be the difference between being able to use certain algorithams with improved settings or not. If this is not the case, then adding such functionality would at least make things easier for the enduser by not requiring the installation of asio4all or such programs.
If I've got how DirectKS works wrong feel free to correct me, I'm interested in learning about it.
However, the fact that people are having better success with asio4all simply shows that on some setups, a cards wdm driver is far superior to its asio driver. The way VirtualDJ operates with wdm drivers at the moment is to run it through kMixer which adds at least 30ms latency to the output and of course suffers from sound quality degradation as kMixer only works in 48khz so it is always resampling. This isn't good for users using their integrated 4.1 and above soundcards. Especially those running a console for control but using their onboard sound.
If I've understood this properly, asio4all provides a wrapper for the wdm driver - its not a real asio driver, but it does run the card using DirectKS which bypasses kMixer, giving the controlling application exclusive access to the card, lower latency and resampling control. If VirtualDJ was able to do this itself then it would free up some resources on the system which could be the difference between being able to use certain algorithams with improved settings or not. If this is not the case, then adding such functionality would at least make things easier for the enduser by not requiring the installation of asio4all or such programs.
If I've got how DirectKS works wrong feel free to correct me, I'm interested in learning about it.
Posted Sat 25 Aug 07 @ 8:53 pm
sbangs
to my understanding its tied into what is used in the new vista sound and video apis
and this is why users found that cards performed better and videos loaded faster and weaker video cards would work ,
Core audio apis in vista (found on dj cels blog):
The core audio APIs are:
Multimedia Device (MMDevice) API
Clients use this API to enumerate the audio endpoint devices in the system.
=> "For enumerating and managing audio endpoints"
Windows Audio Session API (WASAPI)
Clients use this API to create and manage audio streams to and from audio endpoint devices.
=> "Very low level API for rendering audio, render/capture audio streams, adjust volume etc. This API also provides low latency for audio professionals"
DeviceTopology API
Clients use this API to directly access the topological features (for example, volume controls and multiplexers) that lie along the data paths inside hardware devices in audio adapters.
=> "For discovering the internals of an audio card's topology"
EndpointVolume API
Clients use this API to directly access the volume controls on audio endpoint devices. This API is primarily used by applications that manage exclusive-mode audio streams.
The audio core APIs are implemented in the Mmdevapi.dll and Audioses.dll system components, both of which run in user mode.
video about it , :
http://channel9.msdn.com/Showpost.aspx?postid=145665
it could be a good thing as it would mean less resources where being used and you wouldnt get anoying interuptions in your sound , however heres the catch
however to quote microsoft ,it
"results in exclusive access to the audio device, which can break many aspects of the user experience, including disabling warning alert sounds and loss of interoperability with other audio applications. For this reason, the Windows multimedia team actively discourages the direct use of KS properties in applications that do not require such low-level control. For applications that do need this low-level control, the application should relinquish control of the device when the application is not the foreground process and is not actively streaming"
which seems to me like it could be bad news for recording or using external tools , or if you wanted to rewire , which vdj may wish to add in the future
which if this is the case , if a big price to add for reducing a few ms latency
and this is why users found that cards performed better and videos loaded faster and weaker video cards would work ,
Core audio apis in vista (found on dj cels blog):
The core audio APIs are:
Multimedia Device (MMDevice) API
Clients use this API to enumerate the audio endpoint devices in the system.
=> "For enumerating and managing audio endpoints"
Windows Audio Session API (WASAPI)
Clients use this API to create and manage audio streams to and from audio endpoint devices.
=> "Very low level API for rendering audio, render/capture audio streams, adjust volume etc. This API also provides low latency for audio professionals"
DeviceTopology API
Clients use this API to directly access the topological features (for example, volume controls and multiplexers) that lie along the data paths inside hardware devices in audio adapters.
=> "For discovering the internals of an audio card's topology"
EndpointVolume API
Clients use this API to directly access the volume controls on audio endpoint devices. This API is primarily used by applications that manage exclusive-mode audio streams.
The audio core APIs are implemented in the Mmdevapi.dll and Audioses.dll system components, both of which run in user mode.
video about it , :
http://channel9.msdn.com/Showpost.aspx?postid=145665
it could be a good thing as it would mean less resources where being used and you wouldnt get anoying interuptions in your sound , however heres the catch
however to quote microsoft ,it
"results in exclusive access to the audio device, which can break many aspects of the user experience, including disabling warning alert sounds and loss of interoperability with other audio applications. For this reason, the Windows multimedia team actively discourages the direct use of KS properties in applications that do not require such low-level control. For applications that do need this low-level control, the application should relinquish control of the device when the application is not the foreground process and is not actively streaming"
which seems to me like it could be bad news for recording or using external tools , or if you wanted to rewire , which vdj may wish to add in the future
which if this is the case , if a big price to add for reducing a few ms latency
Posted Sun 26 Aug 07 @ 2:25 am
Andrew87
skyfxl wrote :
it could be a good thing as it would mean less resources where being used and you wouldnt get anoying interuptions in your sound , however heres the catch
however to quote microsoft ,it
"results in exclusive access to the audio device, which can break many aspects of the user experience, including disabling warning alert sounds and loss of interoperability with other audio applications. For this reason, the Windows multimedia team actively discourages the direct use of KS properties in applications that do not require such low-level control. For applications that do need this low-level control, the application should relinquish control of the device when the application is not the foreground process and is not actively streaming"
which seems to me like it could be bad news for recording or using external tools , or if you wanted to rewire , which vdj may wish to add in the future
which if this is the case , if a big price to add for reducing a few ms latency
however to quote microsoft ,it
"results in exclusive access to the audio device, which can break many aspects of the user experience, including disabling warning alert sounds and loss of interoperability with other audio applications. For this reason, the Windows multimedia team actively discourages the direct use of KS properties in applications that do not require such low-level control. For applications that do need this low-level control, the application should relinquish control of the device when the application is not the foreground process and is not actively streaming"
which seems to me like it could be bad news for recording or using external tools , or if you wanted to rewire , which vdj may wish to add in the future
which if this is the case , if a big price to add for reducing a few ms latency
No catch there whatsoever, asio4all does the exact same thing (exclusive access). VirtualDJ broadcasts and records too, people shouldn't need to use another application.
Posted Sun 26 Aug 07 @ 2:49 am
sbangs
quite a large number of people have asked for rewiring as a new feature
so a call would have to be made between these two features ultimately
as they wouldnt both work as they use conflicting methods of working
maybe if it could be added as an option like clear sound which could be dissabled
so a call would have to be made between these two features ultimately
as they wouldnt both work as they use conflicting methods of working
maybe if it could be added as an option like clear sound which could be dissabled
Posted Sun 26 Aug 07 @ 4:52 pm
androidi
If the rewire "master" such as Live simply got all channels like preview, master etc etc from the slave (VDJ), the master (Live) would be able to use the Exclusive mode afaik since VDJ isn't talking at all to the kernel mode audio drivers except whatever rewire uses.
Posted Sun 26 Aug 07 @ 10:28 pm
Andrew87
skyfxl wrote :
maybe if it could be added as an option like clear sound which could be dissabled
Yeah, that would work alongside simple / two soundcard config etc. I realise that this would require a complete rewrite (additions) of a possibly large amount of code. The easiest way to do this in the short term would be to bundle the aiso4all driver (with permission) with VirtualDJ and be able to set the asio4all gui options within VirtualDJ itself. All people really need to set in asio4all are their soundcard and latency, both of which are already selectable in VirtualDJ. Therefore if VirtualDJ could act as a frontend for the asio4all utility, things should work ok. Obviously this isn't as good as a native solution and it would require that the author of asio4all is happy for his/her work to be distributed (for free?) in a commerical package.
What androidi mentions is already a feature of the control panel bundled with esi soundcards (DirectWire).
Posted Mon 27 Aug 07 @ 2:21 am
djcel
VirtualDJ already has WDM-KS (WDM Kernel Streaming) for Windows XP ;-)
It's the mode called "Simple Low-Latency" in VirtualDJ
But about Windows Vista, VirtualDJ doesn't contain "Windows Audio Session" system yet
PS:
@skyfxl
Next time, just write a link to my blog ;-)
It's the mode called "Simple Low-Latency" in VirtualDJ
But about Windows Vista, VirtualDJ doesn't contain "Windows Audio Session" system yet
PS:
@skyfxl
Next time, just write a link to my blog ;-)
Posted Sun 23 Sep 07 @ 11:09 pm
androidi
By using ASIO4ALL you already get WaveRT (new Vista API) support. ASIO4ALL is just a thin API wrapper/layer and should not add any meaningful latency.
Another company has a product called REAPER and a virtual ASIO gizmo called ReaRouter ASIO. When you install REAPER you can select ReaRoute ASIO support. With these selected you can hook up VirtualDJ to directly send audio through the virtual ASIO gizmo to REAPER which can be useful if you need to add some mastering/EQ type of stuff to the VDJ master output or maybe record both decks separately etc.
Another company has a product called REAPER and a virtual ASIO gizmo called ReaRouter ASIO. When you install REAPER you can select ReaRoute ASIO support. With these selected you can hook up VirtualDJ to directly send audio through the virtual ASIO gizmo to REAPER which can be useful if you need to add some mastering/EQ type of stuff to the VDJ master output or maybe record both decks separately etc.
Posted Mon 08 Oct 07 @ 6:42 am