ASIO 24 bit bug?

Russ · Aug 18, 2008, 05:06 PM

I was testing some things out with 24 bit ASIO and noticed the following:

In the ASIO host program I recorded 2 stereo tracks.

The first track was direct input from ASIO.
The second track was the host monitored input from the first track.

Both tracks were recorded at the same time.

With the above, where the 2 tracks overlap, they should be identical right?

When looking at the wave files produced in a hex editor, I noticed that they were identical where they overlap each other, except that the right channel appears to be delayed by 1 sample when compared the left channel.

That would seem to be a bug, right?

-Russ

Russ · Aug 19, 2008, 07:39 AM

Hmm, I tried enabling an option in one program to pre-zero the output buffers just to see if it would make a difference and it did. Now the channels appear to match in both tracks (i.e. both tacks are identical where they overlap) .

<edit>
I tried a similar setup with 4 stereo tracks (with the above option disabled), with the (monitored) output of each one feeding the input of the next (i.e. so each track is a delayed version of the previous tracks input). Only the 4th track had the channels out of sync (maybe something to do with being the last one in the chain?). In any case this is not how ASIO would typically be used, so maybe it is not important. I was originally just trying to test for bit accuracy (between ASIO inputs and outputs, etc) and figured this was the easiest way to do it, when I noticed that the channels were out of sync (so I though I would mention it), but if it only does it when daisy chained like this...

Maddogg6 · Aug 19, 2008, 02:06 PM

I dont understand how you can get accurate results ASIO IN vs ASIO IN when using both (FXBus > ASIO in)

What is the out channel set to on the 'monitored' tracks? I presume *not* ASIO 0/1 (I get a buzz from a feedback loop in Sonar if I SW monitor like that)

Maybe.. set up using WDM (with Wave HQ) and use a software rendered wave (form a bounced soft synth) as the 'baseline' object - then record that to another track - maybe clue into if its a host app problem (if same results persist)

Just thinking aloud - and you know what a dumb ass I am about stuff

Russ · Aug 19, 2008, 02:20 PM

There is no feedback because the track that is being monitored is not connected to the same FxBus that is used for ASIO output in the host program.

i.e.
The source audio is ADC (not FxBus 0/1), this is connected to ASIO 0/1 and is what is being monitored in the host program (ASIO 0/1 used for monitoring). FxBus 0/1 is connected to ASIO 2/3, which is the input for the second track. There is no output on the second track since it is not being monitored, so there is no feedback loop.

i.e.
The path is as follows (epilog not shown as it should be obvious):
ADC -> Host (ASIO 0/1 In -> ASIO 0/1 Out) -> FxBus 0/1 -> Host (ASIO 2/3 In) -> nowhere

For the test with 4 tracks I just used separate outputs for monitoring on each track.

Also, (with the first scenario) I tested with two different host programs.

As for WaveHQ, I do not have it...

Tril · Aug 20, 2008, 12:40 AM

It's just a wild guess but maybe the delay in one channel that you encountered is caused by the plugin order in the DSP. If a plugin is connected after another in the DSP but is before in memory, this results in the sample being read on the next cycle/clock of the DSP. This produces a delay of one sample.

Russ · Aug 20, 2008, 07:46 AM

Quote:

Originally Posted by Tril

It's just a wild guess but maybe the delay in one channel that you encountered is caused by the plugin order in the DSP. If a plugin is connected after another in the DSP but is before in memory, this results in the sample being read on the next cycle/clock of the DSP. This produces a delay of one sample.

While that is true, it is not the case here (I only have 3 plugins loaded (FxBusX, ADC, and epilog)).

Russ · Aug 20, 2008, 12:32 PM

OK, here is another test that maybe someone else could try where the source audio is generated in the DSP (so that sample values of the source audio are known (i.e. so we have a "baseline")):

I created a plugin that basically counts down from 0x7fffff (resets at zero). The left channel outputs the counter value directly, while the right channel outputs the counter with the bits inverted. (The values are shifted into the 24 most significant bits in order to preserve the full counter value with 24 bit recording).

i.e. (24 bit values)
Left: 0x7fffff, 0x7fffffe, 0x7ffffd, etc
Right: 0x800000, 0x800001, 0x800002

The count down is triggered with a non-zero slider value (when the slider is zero, output is zero and the counter is reset).

Here is the Dane code for the plugin:

Code:

output left, right;  
static counter = 0x7fffff   
control init = 0;
temp tmp

macs tmp, init, 0, 0;
skip ccr, ccr, 0x8, 0x9;  
macs left, counter, 0, 0;
andxor right, 0xffffffff, left, 0xffffffff;
macints left, 0, left, 0x100;
macints right, 0, right, 0x100;
macw counter, counter, 0x1, 0x80000000;
limit counter, 0, 0x7fffff, counter;        
macs left, 0, left, 0x20000000;
macs right, 0, right, 0x20000000;   
skip ccr, ccr, 0x7fffffff, 0x3;
macs counter, 0x7fffff, 0, 0;
macs left, 0, 0, 0;
macs right, 0, 0, 0;

I tried the same test as before, except using the above plugin instead of ADC:

i.e.
DSP config (consisting of only the test plugin, FxBusX, epilog):
test plugin is connected to ASIO 0/1 in epilog.
FxBusX 0/1 is connected to ASIO 2/3 of epilog.

Host software (wave format set to 24 bit):
Track1: Input is ASIO 0/1, host monitoring is enabled for this track only (using ASIO 0/1 for output)
Track2: Input is ASIO 2/3, host monitoring disabled for this track.

I used an 8ms latency setting.

Both tracks are set to record.

Open the GUI for test plugin, and make sure the slider is at zero.
Start recording, set the slider in the test plugin to any non-zero value, continue recording for a couple of seconds (or whatever), set the slider in the test plugin to zero so that the output stops. Wait until no signal is seen on either track in the host, and then stop recording.

Open the resulting wave files in a hex editor and search for the byte sequence FFFF7F in both wave files (the first hit should be the start of the recording (it should be preceded by zeros)). Compare the two wave files starting from the points found above.

In my test, with the first wave, the sample values match the plugins output exactly (i.e. bit perfect) for both channels (note that the byte values are reversed (this is expected): i.e. 7FFFFF will be seen as FFFF7F).

With the second wave file (as with the previous test), the right channel is delayed by 1 sample when compared with the first wave file (however the values are correct for both channels).

i.e. (bytes aligned for easier comparison, left channel in yellow, right channel in blue)

Code:

: First Wave (24 bit)
...
[COLOR=White]00 00 00 00 00 00 00 00 00 00 00 00
[COLOR=Yellow]FF FF 7F[/COLOR] [COLOR=Cyan]00 00 80[/COLOR] [COLOR=Yellow]FE FF 7F[/COLOR] [COLOR=Cyan]01 00 80[/COLOR]
[COLOR=Yellow]FD FF 7F[/COLOR] [COLOR=Cyan]02 00 80[/COLOR] [COLOR=Yellow]FC FF 7F[/COLOR] [COLOR=Cyan]03 00 80[/COLOR]
[COLOR=Yellow]FB FF 7F[/COLOR] [COLOR=Cyan]04 00 80[/COLOR] [COLOR=Yellow]FA FF 7F[/COLOR] [COLOR=Cyan]05 00 80[/COLOR]
[COLOR=Yellow]F9 FF 7F[/COLOR] [COLOR=Cyan]06 00 80[/COLOR] [COLOR=Yellow]F8 FF 7F[/COLOR] [COLOR=Cyan]07 00 80[/COLOR]
[COLOR=Yellow]F7 FF 7F[/COLOR] [COLOR=Cyan]08 00 80[/COLOR] [COLOR=Yellow]F6 FF 7F[/COLOR] [COLOR=Cyan]09 00 80[/COLOR]
[COLOR=Yellow]F5 FF 7F[/COLOR] [COLOR=Cyan]0A 00 80[/COLOR] [COLOR=Yellow]F4 FF 7F[/COLOR] [COLOR=Cyan]0B 00 80[/COLOR]
...

[/COLOR]: Second Wave (24 bit)
[COLOR=White]...
00 00 00 00 00 00 00 00 00 00 00 00
[COLOR=Yellow]FF FF 7F[/COLOR] [COLOR=White]00 00 00[/COLOR] [COLOR=Yellow]FE FF 7F[/COLOR] [COLOR=Cyan]00 00 80[/COLOR]
[COLOR=Yellow]FD FF 7F[/COLOR] [COLOR=Cyan]01 00 80[/COLOR] [COLOR=Yellow]FC FF 7F[/COLOR] [COLOR=Cyan]02 00 80[/COLOR]
[COLOR=Yellow]FB FF 7F[/COLOR] [COLOR=Cyan]03 00 80[/COLOR] [COLOR=Yellow]FA FF 7F[/COLOR] [COLOR=Cyan]04 00 80[/COLOR]
[COLOR=Yellow]F9 FF 7F[/COLOR] [COLOR=Cyan]05 00 80[/COLOR] [COLOR=Yellow]F8 FF 7F[/COLOR] [COLOR=Cyan]06 00 80[/COLOR]
[COLOR=Yellow]F7 FF 7F[/COLOR] [COLOR=Cyan]07 00 80[/COLOR] [COLOR=Yellow]F6 FF 7F[/COLOR] [COLOR=Cyan]08 00 80[/COLOR]
[COLOR=Yellow]F5 FF 7F[/COLOR] [COLOR=Cyan]09 00 80[/COLOR] [COLOR=Yellow]F4 FF 7F[/COLOR] [COLOR=Cyan]0A 00 80[/COLOR]
...
[/COLOR]

In a followup test, I recorded the playback of the first track, and the resulting wave was the same as with the second wave (above).

BTW: I checked with the pre-zero output buffers option enabled again, and again it seemed to prevent this [COLOR=Gray](this is an option in Reaper, and it appears that Reaper needs to be restarted after toggling this option for it to take effect)[/COLOR].

Maddogg6 · Aug 22, 2008, 01:07 PM

Yup - Same results here in Sonar

Code:

; First 'Primary' wave
[COLOR="YellowGreen"]ff ff 7f [/COLOR][COLOR="Yellow"]00 00 80[/COLOR] [COLOR="YellowGreen"]fe ff 7f[/COLOR] [COLOR="Yellow"]01 00 80[/COLOR] 
[COLOR="YellowGreen"]fd ff 7f[/COLOR] [COLOR="Yellow"]02 00 80[/COLOR] [COLOR="YellowGreen"]fc ff 7f[/COLOR] [COLOR="Yellow"]03 00 80[/COLOR] 
[COLOR="YellowGreen"]fb ff 7f[/COLOR] [COLOR="Yellow"]04 00 80[/COLOR] [COLOR="YellowGreen"]fa ff 7f [/COLOR][COLOR="Yellow"]05 00 80[/COLOR] 
[COLOR="YellowGreen"]f9 ff 7f[/COLOR] [COLOR="Yellow"]06 00 80[/COLOR] [COLOR="YellowGreen"]f8 ff 7f[/COLOR] [COLOR="Yellow"]07 00 80[/COLOR] 


; Secondary Wave
[COLOR="YellowGreen"]ff ff 7f[/COLOR] [COLOR="Yellow"]00 00 00[/COLOR] [COLOR="YellowGreen"]fe ff 7f[/COLOR] [COLOR="Yellow"]00 00 80[/COLOR] 
[COLOR="YellowGreen"]fd ff 7f[/COLOR] [COLOR="Yellow"]01 00 80[/COLOR] [COLOR="YellowGreen"]fc ff 7f [/COLOR][COLOR="Yellow"]02 00 80 [/COLOR]
[COLOR="YellowGreen"]fb ff 7f [/COLOR][COLOR="Yellow"]03 00 80[/COLOR] [COLOR="YellowGreen"]fa ff 7f[/COLOR] [COLOR="Yellow"]04 00 80 [/COLOR]
[COLOR="YellowGreen"]f9 ff 7f[/COLOR] [COLOR="Yellow"]05 00 80[/COLOR] [COLOR="YellowGreen"]f8 ff 7f [/COLOR][COLOR="Yellow"]06 00 80 [/COLOR]
[COLOR="YellowGreen"]f7 ff 7f[/COLOR] [COLOR="Yellow"]07 00 80[/COLOR] [COLOR="YellowGreen"]f6 ff 7f [/COLOR][COLOR="Yellow"]08 00 80 [/COLOR]

I will have to test in 16/48 to see if same thing happens.

Maddogg6 · Aug 22, 2008, 02:25 PM

Update - looks like 16/48 does not suffer from this, tho it was harder to figure out under same circumstances.

There were a series of 'ff 7f 00 80' for 256 (stereo) samples - then changed to 'fe 7f 01 80' - in both files. This of course excludes the latency inherent from recording a monitored track in Sonar - but L vs R samples line up perfectly.

I suspect this was harder to see because they did line up correctly L vs R. But I triple checked by counting wave files address offset differences (address of 'fe 7f 01 80' - address of 'ff 7f 00 80') to make sure the same number of 'ff 7f 00 80' samples occurred in both waves until they changed, and what they changed to.

I hope I made some sense here.

edit:
I do not seem to see an equivalent to a 'pre-zero output buffers' option in sonar. /edit
edit 2: the clsest I see is 'remove DC offset' - which *should* render this test useless as I suspect the test plugins very low freq nature would be muted. /edit

Russ · Aug 22, 2008, 02:37 PM

Thanks for testing.

It does not happen for me at 16/48 either.

BTW: If you want to test 16/48 using the same plugin, the code should be changed slightly, and of course you should record using 16 bit wave format.

(code [COLOR=Cyan]changes[/COLOR] for 16 bit)

Code:

output left, right;  
static counter = [COLOR=Cyan]0x7fff[/COLOR]   
control init = 0;
temp tmp

macs tmp, init, 0, 0;
skip ccr, ccr, 0x8, 0x9;  
macs left, counter, 0, 0;
andxor right, 0xffffffff, left, 0xffffffff;
macints left, 0, left, [COLOR=Cyan]0x10000[/COLOR];
macints right, 0, right, [COLOR=Cyan]0x10000[/COLOR];
macw counter, counter, 0x1, 0x80000000;
limit counter, 0, [COLOR=Cyan]0x7fff[/COLOR], counter;        
macs left, 0, left, 0x20000000;
macs right, 0, right, 0x20000000;   
skip ccr, ccr, 0x7fffffff, 0x3;
macs counter, [COLOR=Cyan]0x7fff[/COLOR], 0, 0;
macs left, 0, 0, 0;
macs right, 0, 0, 0;

With the above the bytes would look like:

Code:

[COLOR=Yellow]FF 7F[/COLOR] [COLOR=Cyan]00 80[/COLOR] [COLOR=Yellow]FE 7F[/COLOR] [COLOR=Cyan]01 80[/COLOR] [COLOR=Yellow]FD 7F[/COLOR] [COLOR=Cyan]02 80[/COLOR]
...

Maddogg6 · Aug 22, 2008, 03:01 PM

I take it - the counter is slower when in 16 bit mode? - it would make sense to me anyway.

Well - anyway, your confirmation assures me that 16/48 works as expected, so I doubt I will do any further testing until maybe E. mentions something changes with this. (or you ask for a new test or something - I already deleted my test project and stuff - and with that, lost ambition too

)

Russ · Aug 22, 2008, 03:08 PM

Hehe, actually the 16 bit counter is faster since it only counts down from 0x7fff (32767) instead of 0x7fffff (8388607). But yeah, even without exact values to use for comparison, it is easy enough to see how they line up (since the delay starts consistently at the first sample of the right channel, you do not have to look far past any non-zero values when comparing).

In any case, thanks again for testing

Maddogg6 · Aug 22, 2008, 03:23 PM

Quote:

I take it - the counter is slower when in 16 bit mode? - it would make sense to me anyway.

So - then - the plugin meant for 24 bit - in 16 bit mode, would count slower - is what I meant. That seemed to be the case with what I observed anyway...

Quote:

In any case, thanks again for testing

Hey, no problem.

Russ · Aug 22, 2008, 04:32 PM

Quote:

Originally Posted by Maddogg6

So - then - the plugin meant for 24 bit - in 16 bit mode, would count slower - is what I meant. That seemed to be the case with what I observed anyway...

It only appears to count slower because the lower 8 bits get truncated.

**Eugene Gavrilov** · Sep 5, 2008, 04:17 PM

it seems that current 24-bit implementation may cause delays between ASIO streams, because there's no way to start up all the streams simultaneously... Also, the DSP seems to introduce a delay if FXBusX microcode is located incorrectly in the DSP. That is, its position influences interchannel delay. I will review this issue soon, but I'm not sure it can be solved easily.

Russ · Sep 5, 2008, 04:36 PM

Hi Eugene, thanks for responding

Personally, I do not think that this issue is really anything major, I just happened to notice it when testing some stuff out, so I thought I should mention it (and I wanted to be sure that it was not just me).

Aug 18, 2008, 05:06 PM	#1
Russ DriverHeaven Extreme Member Join Date: Jan 2005 Posts: 4,836 Rep Power: 41	ASIO 24 bit bug? I was testing some things out with 24 bit ASIO and noticed the following: In the ASIO host program I recorded 2 stereo tracks. The first track was direct input from ASIO. The second track was the host monitored input from the first track. Both tracks were recorded at the same time. With the above, where the 2 tracks overlap, they should be identical right? When looking at the wave files produced in a hex editor, I noticed that they were identical where they overlap each other, except that the right channel appears to be delayed by 1 sample when compared the left channel. That would seem to be a bug, right? -Russ Last edited by Russ; Aug 21, 2008 at 12:48 PM.

Aug 19, 2008, 07:39 AM	#2
Russ DriverHeaven Extreme Member Join Date: Jan 2005 Posts: 4,836 Rep Power: 41	Hmm, I tried enabling an option in one program to pre-zero the output buffers just to see if it would make a difference and it did. Now the channels appear to match in both tracks (i.e. both tacks are identical where they overlap) . <edit> I tried a similar setup with 4 stereo tracks (with the above option disabled), with the (monitored) output of each one feeding the input of the next (i.e. so each track is a delayed version of the previous tracks input). Only the 4th track had the channels out of sync (maybe something to do with being the last one in the chain?). In any case this is not how ASIO would typically be used, so maybe it is not important. I was originally just trying to test for bit accuracy (between ASIO inputs and outputs, etc) and figured this was the easiest way to do it, when I noticed that the channels were out of sync (so I though I would mention it), but if it only does it when daisy chained like this... Last edited by Russ; Aug 21, 2008 at 09:28 AM.

Aug 19, 2008, 02:20 PM	#4
Russ DriverHeaven Extreme Member Join Date: Jan 2005 Posts: 4,836 Rep Power: 41	There is no feedback because the track that is being monitored is not connected to the same FxBus that is used for ASIO output in the host program. i.e. The source audio is ADC (not FxBus 0/1), this is connected to ASIO 0/1 and is what is being monitored in the host program (ASIO 0/1 used for monitoring). FxBus 0/1 is connected to ASIO 2/3, which is the input for the second track. There is no output on the second track since it is not being monitored, so there is no feedback loop. i.e. The path is as follows (epilog not shown as it should be obvious): ADC -> Host (ASIO 0/1 In -> ASIO 0/1 Out) -> FxBus 0/1 -> Host (ASIO 2/3 In) -> nowhere For the test with 4 tracks I just used separate outputs for monitoring on each track. Also, (with the first scenario) I tested with two different host programs. As for WaveHQ, I do not have it... Last edited by Russ; Aug 19, 2008 at 02:44 PM.

Aug 20, 2008, 12:32 PM	#7
Russ DriverHeaven Extreme Member Join Date: Jan 2005 Posts: 4,836 Rep Power: 41	OK, here is another test that maybe someone else could try where the source audio is generated in the DSP (so that sample values of the source audio are known (i.e. so we have a "baseline")): I created a plugin that basically counts down from 0x7fffff (resets at zero). The left channel outputs the counter value directly, while the right channel outputs the counter with the bits inverted. (The values are shifted into the 24 most significant bits in order to preserve the full counter value with 24 bit recording). i.e. (24 bit values) Left: 0x7fffff, 0x7fffffe, 0x7ffffd, etc Right: 0x800000, 0x800001, 0x800002 The count down is triggered with a non-zero slider value (when the slider is zero, output is zero and the counter is reset). Here is the Dane code for the plugin: Code: output left, right; static counter = 0x7fffff control init = 0; temp tmp macs tmp, init, 0, 0; skip ccr, ccr, 0x8, 0x9; macs left, counter, 0, 0; andxor right, 0xffffffff, left, 0xffffffff; macints left, 0, left, 0x100; macints right, 0, right, 0x100; macw counter, counter, 0x1, 0x80000000; limit counter, 0, 0x7fffff, counter; macs left, 0, left, 0x20000000; macs right, 0, right, 0x20000000; skip ccr, ccr, 0x7fffffff, 0x3; macs counter, 0x7fffff, 0, 0; macs left, 0, 0, 0; macs right, 0, 0, 0; I tried the same test as before, except using the above plugin instead of ADC: i.e. DSP config (consisting of only the test plugin, FxBusX, epilog): test plugin is connected to ASIO 0/1 in epilog. FxBusX 0/1 is connected to ASIO 2/3 of epilog. Host software (wave format set to 24 bit): Track1: Input is ASIO 0/1, host monitoring is enabled for this track only (using ASIO 0/1 for output) Track2: Input is ASIO 2/3, host monitoring disabled for this track. I used an 8ms latency setting. Both tracks are set to record. Open the GUI for test plugin, and make sure the slider is at zero. Start recording, set the slider in the test plugin to any non-zero value, continue recording for a couple of seconds (or whatever), set the slider in the test plugin to zero so that the output stops. Wait until no signal is seen on either track in the host, and then stop recording. Open the resulting wave files in a hex editor and search for the byte sequence FFFF7F in both wave files (the first hit should be the start of the recording (it should be preceded by zeros)). Compare the two wave files starting from the points found above. In my test, with the first wave, the sample values match the plugins output exactly (i.e. bit perfect) for both channels (note that the byte values are reversed (this is expected): i.e. 7FFFFF will be seen as FFFF7F). With the second wave file (as with the previous test), the right channel is delayed by 1 sample when compared with the first wave file (however the values are correct for both channels). i.e. (bytes aligned for easier comparison, left channel in yellow, right channel in blue) Code: : First Wave (24 bit) ... [COLOR=White]00 00 00 00 00 00 00 00 00 00 00 00 [COLOR=Yellow]FF FF 7F[/COLOR] [COLOR=Cyan]00 00 80[/COLOR] [COLOR=Yellow]FE FF 7F[/COLOR] [COLOR=Cyan]01 00 80[/COLOR] [COLOR=Yellow]FD FF 7F[/COLOR] [COLOR=Cyan]02 00 80[/COLOR] [COLOR=Yellow]FC FF 7F[/COLOR] [COLOR=Cyan]03 00 80[/COLOR] [COLOR=Yellow]FB FF 7F[/COLOR] [COLOR=Cyan]04 00 80[/COLOR] [COLOR=Yellow]FA FF 7F[/COLOR] [COLOR=Cyan]05 00 80[/COLOR] [COLOR=Yellow]F9 FF 7F[/COLOR] [COLOR=Cyan]06 00 80[/COLOR] [COLOR=Yellow]F8 FF 7F[/COLOR] [COLOR=Cyan]07 00 80[/COLOR] [COLOR=Yellow]F7 FF 7F[/COLOR] [COLOR=Cyan]08 00 80[/COLOR] [COLOR=Yellow]F6 FF 7F[/COLOR] [COLOR=Cyan]09 00 80[/COLOR] [COLOR=Yellow]F5 FF 7F[/COLOR] [COLOR=Cyan]0A 00 80[/COLOR] [COLOR=Yellow]F4 FF 7F[/COLOR] [COLOR=Cyan]0B 00 80[/COLOR] ... [/COLOR]: Second Wave (24 bit) [COLOR=White]... 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR=Yellow]FF FF 7F[/COLOR] [COLOR=White]00 00 00[/COLOR] [COLOR=Yellow]FE FF 7F[/COLOR] [COLOR=Cyan]00 00 80[/COLOR] [COLOR=Yellow]FD FF 7F[/COLOR] [COLOR=Cyan]01 00 80[/COLOR] [COLOR=Yellow]FC FF 7F[/COLOR] [COLOR=Cyan]02 00 80[/COLOR] [COLOR=Yellow]FB FF 7F[/COLOR] [COLOR=Cyan]03 00 80[/COLOR] [COLOR=Yellow]FA FF 7F[/COLOR] [COLOR=Cyan]04 00 80[/COLOR] [COLOR=Yellow]F9 FF 7F[/COLOR] [COLOR=Cyan]05 00 80[/COLOR] [COLOR=Yellow]F8 FF 7F[/COLOR] [COLOR=Cyan]06 00 80[/COLOR] [COLOR=Yellow]F7 FF 7F[/COLOR] [COLOR=Cyan]07 00 80[/COLOR] [COLOR=Yellow]F6 FF 7F[/COLOR] [COLOR=Cyan]08 00 80[/COLOR] [COLOR=Yellow]F5 FF 7F[/COLOR] [COLOR=Cyan]09 00 80[/COLOR] [COLOR=Yellow]F4 FF 7F[/COLOR] [COLOR=Cyan]0A 00 80[/COLOR] ... [/COLOR] In a followup test, I recorded the playback of the first track, and the resulting wave was the same as with the second wave (above). BTW: I checked with the pre-zero output buffers option enabled again, and again it seemed to prevent this [COLOR=Gray](this is an option in Reaper, and it appears that Reaper needs to be restarted after toggling this option for it to take effect)[/COLOR]. Last edited by Russ; Aug 21, 2008 at 09:30 AM. Reason: typo

Aug 22, 2008, 02:25 PM	#9
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 36	Update - looks like 16/48 does not suffer from this, tho it was harder to figure out under same circumstances. There were a series of 'ff 7f 00 80' for 256 (stereo) samples - then changed to 'fe 7f 01 80' - in both files. This of course excludes the latency inherent from recording a monitored track in Sonar - but L vs R samples line up perfectly. I suspect this was harder to see because they did line up correctly L vs R. But I triple checked by counting wave files address offset differences (address of 'fe 7f 01 80' - address of 'ff 7f 00 80') to make sure the same number of 'ff 7f 00 80' samples occurred in both waves until they changed, and what they changed to. I hope I made some sense here. edit: I do not seem to see an equivalent to a 'pre-zero output buffers' option in sonar. /edit edit 2: the clsest I see is 'remove DC offset' - which should render this test useless as I suspect the test plugins very low freq nature would be muted. /edit Last edited by Maddogg6; Aug 22, 2008 at 02:38 PM. Reason: oops. made no sense in a spot

Aug 19, 2008, 02:06 PM	#3
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 36	I dont understand how you can get accurate results ASIO IN vs ASIO IN when using both (FXBus > ASIO in) What is the out channel set to on the 'monitored' tracks? I presume not ASIO 0/1 (I get a buzz from a feedback loop in Sonar if I SW monitor like that) Maybe.. set up using WDM (with Wave HQ) and use a software rendered wave (form a bounced soft synth) as the 'baseline' object - then record that to another track - maybe clue into if its a host app problem (if same results persist) Just thinking aloud - and you know what a dumb ass I am about stuff

Aug 20, 2008, 12:40 AM	#5
Tril S-3D enthusiast Join Date: Sep 2004 Location: Canada Posts: 1,561 Rep Power: 39 System Specs	It's just a wild guess but maybe the delay in one channel that you encountered is caused by the plugin order in the DSP. If a plugin is connected after another in the DSP but is before in memory, this results in the sample being read on the next cycle/clock of the DSP. This produces a delay of one sample.

Aug 22, 2008, 03:01 PM	#11
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 36	I take it - the counter is slower when in 16 bit mode? - it would make sense to me anyway. Well - anyway, your confirmation assures me that 16/48 works as expected, so I doubt I will do any further testing until maybe E. mentions something changes with this. (or you ask for a new test or something - I already deleted my test project and stuff - and with that, lost ambition too )

Aug 22, 2008, 03:08 PM	#12
Russ DriverHeaven Extreme Member Join Date: Jan 2005 Posts: 4,836 Rep Power: 41	Hehe, actually the 16 bit counter is faster since it only counts down from 0x7fff (32767) instead of 0x7fffff (8388607). But yeah, even without exact values to use for comparison, it is easy enough to see how they line up (since the delay starts consistently at the first sample of the right channel, you do not have to look far past any non-zero values when comparing). In any case, thanks again for testing

Sep 5, 2008, 04:17 PM	#15
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,037 Rep Power: 56	it seems that current 24-bit implementation may cause delays between ASIO streams, because there's no way to start up all the streams simultaneously... Also, the DSP seems to introduce a delay if FXBusX microcode is located incorrectly in the DSP. That is, its position influences interchannel delay. I will review this issue soon, but I'm not sure it can be solved easily.

Sep 5, 2008, 04:36 PM	#16
Russ DriverHeaven Extreme Member Join Date: Jan 2005 Posts: 4,836 Rep Power: 41	Hi Eugene, thanks for responding Personally, I do not think that this issue is really anything major, I just happened to notice it when testing some stuff out, so I thought I should mention it (and I wanted to be sure that it was not just me).

LinkBacks (?) LinkBack to this Thread: http://www.driverheaven.net/bug-reports/166999-asio-24-bit-bug.html
Posted By	For	Type	Date
Bug Reports on DriverHeaven.net \| BoardReader	This thread	Refback	Sep 1, 2008 06:37 PM

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
3544 bug reports (24 bit asio, E-DSP)	Eugene Gavrilov	Bug Reports	39	Aug 12, 2008 12:58 AM
3543 bug reports (24 bit asio, E-DSP)	Eugene Gavrilov	Bug Reports	20	Jul 27, 2008 12:06 AM
ASIO Bug?	Eminos	ASIO	11	Jan 17, 2005 07:51 PM
24-bit ASIO support /2.ZS	Michel	ASIO	1	Aug 11, 2004 04:11 PM
BUG: KX Project startup with Native Instruments B4 in ASIO - crash	obxwindsurf	Bug Reports	6	Dec 18, 2003 08:47 AM