Writing drivers

Quince · Apr 19, 2007, 10:20 AM

I came up with a USB DAC design that rejects all external jitter; it's jitter is only limited by the DAC's local clock. However, I've no idea of the best way to deal with software on the PC side (I'm a software developer, but don't have experience with drivers), since it's not a synchronous connection such as S/PDIF. I'm posting here, as the kx writers would seem the people most qualified to answer my question.

I assume the DAC has a constant bitrate/sampling frequency, and I'll do the resampling in software on the PC side. My issue is how to bypass things like windows volume control etc (I've read that you lose the LSB even if the windows control is set to max). I intend to have the USB DAC poll the system for more data, so that the local clock is controlling, rather than the PC pushing the stream based on its own clock. I'm not sure how a sound player under Windows controls the rate it streams data at. Is it based on local CPU clock, or the soundcard, or what? Is my best option to go with a plugin for players instead of a driver, etc? Any info greatly appreciated. You can reply here or contact me by email.

Russ · Apr 21, 2007, 04:31 AM

I think you should probably ask your questions in a forum specifically about audio driver development.

Aside form the above, I do not know much about driver devleopment, but as far as the Windows volume goes, I do not see why it would be a problem. As I understand it, you do not need to implement any Windows volume controls that you do not want to, but beyond that, I do not see why you would lose the LSB. Again, as I understand it, it just notifies the driver of the current setting, and the driver does the actual work of adjusting the volume, so any inaccuracies related to volume would be due to how its is handled by the driver.

Quince · Apr 21, 2007, 07:40 AM

My understanding was that regardless of the output device, be it sound card whatever, sound still goes through the application volume control, then Windows volume control (same one as in Volume tab in Multimedia Properties), before it's outputted.

Regarding the playback application, I'm wondering if WMP or VLC or Winamp etc. all leave original datastream untouched if equalizer and other such DSP are off and application volume set to maximum.

Regarding the Windows volume control, my understanding is that unless AISO is used it goes through that and someone told me you lose the LSB even with that control to max.

I guess my goal is how to prevent any DSP including digital volume control being applied to the stream. So when I play say a .wav, I'd get bit-accurate stream available to the driver.

And the clock issue--what controls the timing? If say I have 96 kHz sampling rate, does Windows use the CPU to determine when the 10.417 microseconds have elapsed to send the next sample? Or can the sound hardware control the streaming rate?

Russ · Apr 21, 2007, 02:21 PM

Again, I do not know a lot about driver devlopment, but I am confused by your questions. Your are talking about a DAC, right? So, your device would be the output device, no? Why worry about what happens within external software (you have no control over it)? I think the only thing you would need to worry about is what your device does to the signal, no?

jiiteepee · Apr 21, 2007, 03:06 PM

In most cases, playback applications volume control can be bypassed w/ using native ASIO or WDM/KS (incl. asio4all, asiox, asio2ks, etc. wrappers). There also are native ASIO capable playback software (as like NativeInstruments BeatPort Player) available which do not let you bypass the internal (software) volume control.

You can bypass the "Windows volume control" only by removing the "Mixer Device" listed in Device Manager->Sound, Video and Game Controllers->your audio device (if your DAC becomes not listed there, maybe removing mixer for onboard sound is enough in this case).

If your system recognizes your USB DAC as an audio device, it's possible that asio4all drivers works for you right away (it's possible that you'll even get bit-perfect connection).
If system doesn't list the DAC as an audio device, you'll need to program an USB Audio driver by yourself. Best place to get information/instructions for this work is the Microsoft (Driver) Developers Comminity found @ microsoft.com. After you have a WDM driver (w/ KS support) for your DAC available, you can use asio4all or similiar wrapper w/ your DAC. If you prefer to program native ASIO drivers only, I can't give any directions but Steinberg ASIO SDK (dunno, if there are all you need). Other needed information comes from those manufacturers whos components (Controller chip, DAC chip, etc.) you have in your USB DAC.

IMO, it's much easier for you if you just use some audio device (onboard sound goes well if it has needed digital path) for streaming the signal through its S/PDIF (optical/coaxial) into your DAC.

jiitee

Quince · Apr 21, 2007, 11:13 PM

S/PDIF is a synchronous interface, which is the main cause of jitter issues and is exactly what I want to avoid. Hawksford's AES paper is a classic explanation of the faults of S/PDIF: http://www.scalatech.co.uk/papers/aes93.pdf S/PDIF is not really fully digital because the stream clock is recovered by a PLL in the DAC from the signal's rise and fall times which is analog information. By dropping S/PDIF and using a bidirectional asynchronous interface, I can reject all external jitter.

My most important question remains, that of what controls the timing of the streaming? Is that up to the driver, or to Windows, or the player? I'm not talking about the sample rate itself, but the actual clock. Does Windows or the application force the use of the CPU to determine timing, or is the driver able to make the sound hardware clock be used?

Quince · May 12, 2007, 11:20 AM

I just noticed that the USB Audio standard does not provide for error correction! That's terrible... Someone that has a USB analyzer told me in USB Audio isochronous mode there's significant amount of errors with Windows computers, though far less with MACs and Linux. For the past few years USB chipsets seem to support isochronous mode in firmware, whereas Windows doesn't take advantage of that and so the problems.

It seems bulk transfer may be better for Windows PCs, as even though it's incompatible with the USB Audio standard and latency is an issue, at least one is going to get bit-perfect output. I wonder how difficult it would be to do a sound driver that directs output to regular USB interface.

Apr 19, 2007, 10:20 AM	#1
Quince DriverHeaven Junior Member Join Date: Oct 2003 Posts: 32 Rep Power: 0	Writing drivers I came up with a USB DAC design that rejects all external jitter; it's jitter is only limited by the DAC's local clock. However, I've no idea of the best way to deal with software on the PC side (I'm a software developer, but don't have experience with drivers), since it's not a synchronous connection such as S/PDIF. I'm posting here, as the kx writers would seem the people most qualified to answer my question. I assume the DAC has a constant bitrate/sampling frequency, and I'll do the resampling in software on the PC side. My issue is how to bypass things like windows volume control etc (I've read that you lose the LSB even if the windows control is set to max). I intend to have the USB DAC poll the system for more data, so that the local clock is controlling, rather than the PC pushing the stream based on its own clock. I'm not sure how a sound player under Windows controls the rate it streams data at. Is it based on local CPU clock, or the soundcard, or what? Is my best option to go with a plugin for players instead of a driver, etc? Any info greatly appreciated. You can reply here or contact me by email.

Apr 21, 2007, 03:06 PM	#5
jiiteepee HardwareHeaven Senior Member Join Date: Apr 2005 Location: FI Posts: 400 Rep Power: 0	In most cases, playback applications volume control can be bypassed w/ using native ASIO or WDM/KS (incl. asio4all, asiox, asio2ks, etc. wrappers). There also are native ASIO capable playback software (as like NativeInstruments BeatPort Player) available which do not let you bypass the internal (software) volume control. You can bypass the "Windows volume control" only by removing the "Mixer Device" listed in Device Manager->Sound, Video and Game Controllers->your audio device (if your DAC becomes not listed there, maybe removing mixer for onboard sound is enough in this case). If your system recognizes your USB DAC as an audio device, it's possible that asio4all drivers works for you right away (it's possible that you'll even get bit-perfect connection). If system doesn't list the DAC as an audio device, you'll need to program an USB Audio driver by yourself. Best place to get information/instructions for this work is the Microsoft (Driver) Developers Comminity found @ microsoft.com. After you have a WDM driver (w/ KS support) for your DAC available, you can use asio4all or similiar wrapper w/ your DAC. If you prefer to program native ASIO drivers only, I can't give any directions but Steinberg ASIO SDK (dunno, if there are all you need). Other needed information comes from those manufacturers whos components (Controller chip, DAC chip, etc.) you have in your USB DAC. IMO, it's much easier for you if you just use some audio device (onboard sound goes well if it has needed digital path) for streaming the signal through its S/PDIF (optical/coaxial) into your DAC. jiitee __________________ Last edited by jiiteepee; Apr 21, 2007 at 04:18 PM.

Apr 21, 2007, 04:31 AM	#2
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	I think you should probably ask your questions in a forum specifically about audio driver development. Aside form the above, I do not know much about driver devleopment, but as far as the Windows volume goes, I do not see why it would be a problem. As I understand it, you do not need to implement any Windows volume controls that you do not want to, but beyond that, I do not see why you would lose the LSB. Again, as I understand it, it just notifies the driver of the current setting, and the driver does the actual work of adjusting the volume, so any inaccuracies related to volume would be due to how its is handled by the driver.

Apr 21, 2007, 07:40 AM	Thread Starter #3
Quince DriverHeaven Junior Member Join Date: Oct 2003 Posts: 32 Rep Power: 0	My understanding was that regardless of the output device, be it sound card whatever, sound still goes through the application volume control, then Windows volume control (same one as in Volume tab in Multimedia Properties), before it's outputted. Regarding the playback application, I'm wondering if WMP or VLC or Winamp etc. all leave original datastream untouched if equalizer and other such DSP are off and application volume set to maximum. Regarding the Windows volume control, my understanding is that unless AISO is used it goes through that and someone told me you lose the LSB even with that control to max. I guess my goal is how to prevent any DSP including digital volume control being applied to the stream. So when I play say a .wav, I'd get bit-accurate stream available to the driver. And the clock issue--what controls the timing? If say I have 96 kHz sampling rate, does Windows use the CPU to determine when the 10.417 microseconds have elapsed to send the next sample? Or can the sound hardware control the streaming rate?

Apr 21, 2007, 02:21 PM	#4
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	Again, I do not know a lot about driver devlopment, but I am confused by your questions. Your are talking about a DAC, right? So, your device would be the output device, no? Why worry about what happens within external software (you have no control over it)? I think the only thing you would need to worry about is what your device does to the signal, no?

Apr 21, 2007, 11:13 PM	Thread Starter #6
Quince DriverHeaven Junior Member Join Date: Oct 2003 Posts: 32 Rep Power: 0	S/PDIF is a synchronous interface, which is the main cause of jitter issues and is exactly what I want to avoid. Hawksford's AES paper is a classic explanation of the faults of S/PDIF: http://www.scalatech.co.uk/papers/aes93.pdf S/PDIF is not really fully digital because the stream clock is recovered by a PLL in the DAC from the signal's rise and fall times which is analog information. By dropping S/PDIF and using a bidirectional asynchronous interface, I can reject all external jitter. My most important question remains, that of what controls the timing of the streaming? Is that up to the driver, or to Windows, or the player? I'm not talking about the sample rate itself, but the actual clock. Does Windows or the application force the use of the CPU to determine timing, or is the driver able to make the sound hardware clock be used?

May 12, 2007, 11:20 AM	Thread Starter #7
Quince DriverHeaven Junior Member Join Date: Oct 2003 Posts: 32 Rep Power: 0	I just noticed that the USB Audio standard does not provide for error correction! That's terrible... Someone that has a USB analyzer told me in USB Audio isochronous mode there's significant amount of errors with Windows computers, though far less with MACs and Linux. For the past few years USB chipsets seem to support isochronous mode in firmware, whereas Windows doesn't take advantage of that and so the problems. It seems bulk transfer may be better for Windows PCs, as even though it's incompatible with the USB Audio standard and latency is an issue, at least one is going to get bit-perfect output. I wonder how difficult it would be to do a sound driver that directs output to regular USB interface.