MQN

[jesuscheung]

the ideal is to use dma transfer rather than copying data through the cpu, using a usb/spdif convertor doesn't allow for this option. think you can do it with a soundcard or dedicated device. not sure if the m50 does this.

That's a bit like windows' WaveRT in the PortCls.

Don't know which/what sort of audio devices support this model.

http://www.sm5bsz.com/lir/rxdel/3-26out/rxout.htm

apparently my soundcard sucks at DMA compared to other soundcards. don't see USB DAC in the list.

actually don't quite understand DMA. is this like native ASIO's DMA?

Delta 44 zero delay in xp. professional soundcard. PCI... who has PCI nowaday

[Aleg]

the ideal is to use dma transfer rather than copying data through the cpu, using a usb/spdif convertor doesn't allow for this option. think you can do it with a soundcard or dedicated device. not sure if the m50 does this.

That's a bit like windows' WaveRT in the PortCls.

Don't know which/what sort of audio devices support this model.

http://www.sm5bsz.com/lir/rxdel/3-26out/rxout.htm

apparently my soundcard sucks at DMA compared to other soundcards. don't see USB DAC in the list.

actually don't quite understand DMA. is this like native ASIO's DMA?

DMA = Direct Memory Access,

Windows' PortClass-drivers use it

[jesuscheung]

if CPU isn't sending the audio stream, i imagine you need DMA controller to stream.

the question is: DMA controller>CPU?

maybe that M50 mobo has a DMA controller that has direct access to both harddisk + DAC. most direct streaming can be imagined. maybe that's why it doesn't need a good CPU.

[jkeny]

I think what Gordon understands by DMA is a connection that doesn't involve the CPU?

This was one of the hopeful advantages of the Haswell CPUs, I thought? i.e handing over communication to the audio device for it to directly access the PC's memory to retrieve the audio files - this is a simplistic statement of what DMA involves I know but the idea of the CPU not being direct;y involved has certain advantages. Unfortunately, it probably has to await devices that can take advantage of this feature.

Can someone who knows more about this explain, expand & outline what has to be implemented?

[jkeny]

if CPU isn't sending the audio stream, i imagine you need DMA controller to stream.

the question is: DMA controller>CPU?

maybe that M50 mobo has a DMA controller that has direct access to both harddisk + DAC. most direct streaming can be imagined. maybe that's why it doesn't need a good CPU.

Yea, it's a good question, JC - DMA controller may not be any less noise inducing than CPU processing. The problem with all this is that only experimenting can answer this question

[sbgk]

don't we currently have dma controller as well as cpu copy so all that is happening is cpu copy is being removed. I would say jplay must be getting close to the best solution using cpu copy, unfortunately they are sticking with 2 engines that don't sound natural to me.

I would say mdppup is an example of what can be achieved with a minimal o/s, unfortunately the player isn't dynamic enough - presumably mpd could be improved.

read up about ks to understand the dma copy options

[jesuscheung]

DMA is interesting. reading it. DMA feels very fast like speed of light. but can it transfer data steadily with good timing?

[jesuscheung]

in case you haven't read ASIO4ALL changelog. it has some helpful experience with KS DMA (since ASIO4ALL is built around KS).
http://tippach.business.t-online.de/asi ... story.html

1.0 (Final) year 2004
"Added Direct DMA Buffer I/O for devices that support it. This mode is very soft on the CPU and latencies can be achieved that are equal to the values one gets with pro gear...."

"In order to understand why this works on some systems and on others it does not, one needs to know that WDM audio drivers come in two flavors: WaveCyclic and WavePci. We only have a chance with WavePci, because these drivers do not actually copy audio data from our buffer but rather make the buffer we submit to them their current DMA buffer. But we still know where our buffers are, even after we submitted them to the WDM audio driver, right? Thus, when writing to the buffer currently being played, we are writing directly to the DMA buffer! The tricky bit is to figure out where exactly to write and how to keep things in sync."

" Unfortunately, most consumer grade stuff comes with WaveCyclic type drivers only, it seems."


http://tippach.business.t-online.de/asi ... story.html
Q: Any hints on using ASIO4ALL with USB devices?

A: After some initial troubles with earlier revisions, the driver now appears to work just fine with numerous USB devices. one thing to not do, I mean: not ever! is to check the DMA box with USB devices. If you do not need all the additional software gizmos like EAX, EQ, Fake3D-Whatever... it is recommended that you _not_ install the drivers shipped with your USB audio interface. Windows has a built-in generic USB audio driver that works with most devices. Thus, if you want to have honest, no-nonsense, low-latency audio playback/recording with your USB audio interface - by all means: stick with the Windows driver! This is especially true for consumer grade stuff, where you can be assured that the drivers shipped with it are most likely 'consumer grade' as well.

[Aleg]

in case you haven't read ASIO4ALL changelog. it has some helpful experience with KS DMA (since ASIO4ALL is built around KS).
http://tippach.business.t-online.de/asi ... story.html

1.0 (Final) year 2004
"Added Direct DMA Buffer I/O for devices that support it. This mode is very soft on the CPU and latencies can be achieved that are equal to the values one gets with pro gear...."

"In order to understand why this works on some systems and on others it does not, one needs to know that WDM audio drivers come in two flavors: WaveCyclic and WavePci. We only have a chance with WavePci, because these drivers do not actually copy audio data from our buffer but rather make the buffer we submit to them their current DMA buffer. But we still know where our buffers are, even after we submitted them to the WDM audio driver, right? Thus, when writing to the buffer currently being played, we are writing directly to the DMA buffer! The tricky bit is to figure out where exactly to write and how to keep things in sync."

" Unfortunately, most consumer grade stuff comes with WaveCyclic type drivers only, it seems."


http://tippach.business.t-online.de/asi ... story.html
Q: Any hints on using ASIO4ALL with USB devices?

A: After some initial troubles with earlier revisions, the driver now appears to work just fine with numerous USB devices. one thing to not do, I mean: not ever! is to check the DMA box with USB devices. If you do not need all the additional software gizmos like EAX, EQ, Fake3D-Whatever... it is recommended that you _not_ install the drivers shipped with your USB audio interface. Windows has a built-in generic USB audio driver that works with most devices. Thus, if you want to have honest, no-nonsense, low-latency audio playback/recording with your USB audio interface - by all means: stick with the Windows driver! This is especially true for consumer grade stuff, where you can be assured that the drivers shipped with it are most likely 'consumer grade' as well.

Part of it at least is outdated:
"WDM audio drivers come in two flavors: WaveCyclic and WavePci"

There exists also a 3rd flavor WaveRT (Wave RealTime) see my picture above. Microsoft site has a lot of information about audio drivers

[jesuscheung]

in case you haven't read ASIO4ALL changelog. it has some helpful experience with KS DMA (since ASIO4ALL is built around KS).
http://tippach.business.t-online.de/asi ... story.html

1.0 (Final) year 2004
"Added Direct DMA Buffer I/O for devices that support it. This mode is very soft on the CPU and latencies can be achieved that are equal to the values one gets with pro gear...."

"In order to understand why this works on some systems and on others it does not, one needs to know that WDM audio drivers come in two flavors: WaveCyclic and WavePci. We only have a chance with WavePci, because these drivers do not actually copy audio data from our buffer but rather make the buffer we submit to them their current DMA buffer. But we still know where our buffers are, even after we submitted them to the WDM audio driver, right? Thus, when writing to the buffer currently being played, we are writing directly to the DMA buffer! The tricky bit is to figure out where exactly to write and how to keep things in sync."

" Unfortunately, most consumer grade stuff comes with WaveCyclic type drivers only, it seems."


http://tippach.business.t-online.de/asi ... story.html
Q: Any hints on using ASIO4ALL with USB devices?

A: After some initial troubles with earlier revisions, the driver now appears to work just fine with numerous USB devices. one thing to not do, I mean: not ever! is to check the DMA box with USB devices. If you do not need all the additional software gizmos like EAX, EQ, Fake3D-Whatever... it is recommended that you _not_ install the drivers shipped with your USB audio interface. Windows has a built-in generic USB audio driver that works with most devices. Thus, if you want to have honest, no-nonsense, low-latency audio playback/recording with your USB audio interface - by all means: stick with the Windows driver! This is especially true for consumer grade stuff, where you can be assured that the drivers shipped with it are most likely 'consumer grade' as well.

Part of it at least is outdated:
"WDM audio drivers come in two flavors: WaveCyclic and WavePci"

There exists also a 3rd flavor WaveRT (Wave RealTime) see my picture above. Microsoft site has a lot of information about audio drivers

that's good news!

try install asio4all with foobar, tick "hardware buffer" or WaveRT, set all buffers to maximum, and see if DMA works or not!

i tried with my soundcard, need big buffer to work. using "hardware buffer", or DMA (as i assumed it is the same thing), ASIO4ALL or KS starts to sound like my native ASIO.