Eugene Gavrilov

hello

as most of you already know, ac-3 passthru mode is currently implemented for audigy cards only. however, it possibly works for Live!s, too...

in order to verify if ac-3 passthru method implemented for 10k2-based boards works with 10k1-based cards it is necessary to perform some tests:

download and install the latest development release (3533)
reboot if necessary
reset your DSP settings via kX DSP
add 'B2B' (located in the 'passthru' group) plugin between 'FXBUS4,5' and 'XRouting'
in the kX DSP connect B2B outputs to epilog.asio4 and epilog.asio5 (or any other input except asio1 and asio3 for '5.1' cards)

now use any text editor to create a text file with any text you wish
(at least 64 symbols)
open SoundForge or similar tool and 'import' the text file as a 'RAW' sound file
with the following parameters: 16 bit, signed, 48000, stereo
save the file as generic 'PCM' file

now configure 'SoundForge' to work with 'kX Wave 4/5' device
set it to playback audio data in a loop

open any ASIO client (such as Cubase), or, preferrably, WaveLab (4.0) or Sonar (2.2) in ASIO mode
set it to record from the ASIO source you specified in kX DSP
(as usual, 16bit/48000/stereo)

turn off your speakers and / or headphones

start looped playback via SoundForge or similar tool of the 'text' file
start the recording via ASIO client

wait 5-10 sec

stop everything

now, save the recorded audio data in 'RAW' format (or generic PCM; it should be 16bit/signed/48000/stereo)

in any text editor open the recorded WAV file and check if its content
is similar to the 'original' text

it is expected that the present passthru method functions correctly for all 10k1-based boards
with chip revision >=7 (you can check it via 'About...' dialog box. note that the
revision number is hexadecimal)

if the resulting file doesn't look similar to the original one (that is,
most of the characters are replaced), then the present passthru method cannot be
used with your card.

in order to minimize any possible 'false' failures, you may try to clear the DSP and
upload only 'fxbus', 'b2b' and 'epilog' effects
you may also try checking the signal path by using 'peak' plugin

note: avoid loopbacks! the recording ASIO data will be played back by ASIO client
make sure you either use different input and output channels or mute the recording source

please specify your card information displayed by 'about...' dialog box in your reports

/Eugene

p.s.
unfortunately, we cannot test this ourselves because we don't have Live!s with
chip revision >= 7

Mata Hari

Well, close... :-)

first, info:
----Hardware / Software configuration---------------
Driver Name:kX Audio Driver (Debug)
Driver Date: May 7 2003 08:28:18
Driver Version: 5.10.00.3533 - debug
DB Name:LiveBay1
SB0060 5.1 [d000]
PCI Information:
Device: 21102 Subsys: 80611102 ChipRev: 7
Card has MPU device
Card model is '5.1'
Card HAS AC97 codec
Codec name: SigmaTel STAC9708
3D Extension: SigmaTel 3D Enhancement
Codec is 2.0 compliant
Capabilities[6940] :
DAC resolutions : -16-bit- -18-bit-
ADC resolutions : -16-bit- -18-bit-
Ext Capabilities [80]: -PCM surround DAC-
Port: d000 Irq: 12
Playback buffer: 20a0
Record buffer: 4000
Number of AC3 buffers: 4
Tank memory: 256 kb
OS version: [2 5 0 Service Pack 3; 2 5 0 Service Pack 3; 156 148]

(SB0060, chip 7)

Now, I had to use some other programs (samplitude and cooledit) cause I dont have SoundForge and WaveLab...

Because I got way diffrent data, wich looked like signed to me, I set up the dsp a bit different

I used 2 direct connections, to establish which of the signals are the non processed (why? well, read on :-)

anyways, the resulting waves were very close... 2 of them were the same, as one would guess, the 3th was very close to the same, all the MSB's (or LSB's dunno wich one :-)) were shifted 1 byte up

hex code from ultra edit (deleted the riff header):

I have a ac3 external decoder connected digitally, if I can figure it out, I'll try to actually test if it works when playing ac3 files... (or am I mistaking this thing for what it does now?)

ps.
the original file was
Test0001Test0002Test0003Test0004Test0005Test0006Te st0007Test0008

it kinda looks like cooledit f*cked that up a bit with signed/unsigned :-)

Mata Hari

Well, I don't think it works, or I don't know how to set it up at all (I hope the last :-)

Tried to play an ac3 wave conected my decoder with both the digital din and coax, neither worked...

or should I have some special player for this?
or does anybody have a test program for this?
or am I just having false hopes, and that it just don't work? :-)

Mata Hari

k, I found an ac3 avi test file, played it with direct spdif output, and the sound sounded choppy, and only came from front... the spdif popup did flash... is this what this is used for? and if so, how do I fit in the b2b? (apparently, simply connecting wave0/1 or 4/5 to b2b to spdif 1 (digital front) did not quite do the trick

gooday

I hope more people in the world help you solve this.

__________________
CPU:AMD Phenom II 550
Video :AMD 4850 @ 625/2008
Memory: 2 GB X 2 DDR1600@8-8-8-21-1T
SoundCard1:SB0060 & CT4620
Mainboard:AMD 770

Eugene Gavrilov

actually the data should be 100% -identical-
that is, if the wav file contains 'hello, kX', the recorded data should contain the same text
[if everything works correctly]

make sure you have all your volumes set to 'maximum' (Wave Volume, Rec Level)

I've uploaded a test .wav file that I usually use for my testing (well, it is actually msdos.ini )
http://kx.maincore.nl/beta/test.wav
(new screenshots similar to the ones you created should be sufficient for me to decide if the feature is supported)

make sure you don't have any additional settings turned on in your audio application (such as 'dither', '24bit processing', etc.. etc.. - playing via regular DirectX application might be more reliable -- note: it should be 'looped' - otherwise some initial/final interpolation might happen)

any non-asio clients, unfortunately, will get the data dithered (due to the nature of the hardware)
according to my tests, Cubase usually modifies the ASIO-recorded data (but WaveLab doesn't)
so, negative results might be caused by incorrect software environment...

/Eugene

P.S.

in order to use this feature for ac-3 passthru, you need to set spdif output status to 'not-audio'

(via kxctrl: but this is not the case -- the driver will do this for you when we figure out how to 'passthru' the data; anyway, the 'correct' status is '0x2108506' for ac-3 and '0x2108504' for 'generic' spdif data;
the registers to tweak: 54, 55, 56 (e.g.: kxctrl -sptr 54 0 <status>); -gptr or 'kxctrl -istat' will display the present status)

anyway, don't expect ac-3 passthru to work with the present driver release
but 'unmodified recording' should work (somehow...)

Mata Hari

Well... I actually *think* the b2b actually does work... however, there are some other very weird bugs...

been fiddling with it a few hours, and this is what I got..

First of all, I now did use wavelab and sonic foundry to test it all...

Loaded the wave into foundry, checked options etc (no dithering, 16 bits output, the works, same idea as with cooledit)
Used wavelab as asio recorder, also set that up correctly (afaik, and I do kinda trust me of being able to set up the programs corectly, also with cooledit/samplitude :-))

first then, a bug that has been around for quite some time, And I thought, was an samplitude error, but wavelabs has it also...
Asio epilog 15/16 does not corrospond with the asio 15/16 reported in the programs, 15/16 becomes 1/2 in wavelab/samplitude, 14/15 becomes 15/16, didnt check the others
I also do have to note that in samplitude, in previous releases of the driver, the asio recording channels seemed to be mixed up even more, even random sometimes... (epilog 14/15 coming out of 7/8, next start of the program 8/9, so even over the stereo boundry... Dunno if that is still the case (it looked kinda to stay at 1/2 & 14/16 now)

that's bug 1 :-)

now, the actual wave file recording itself...

first through b2b... file was half correct, all msb's failed (or lsb's, still don't know wichones, think it was msb, lsb on intel, if so, then I think msb's), rest was ok...

now the intresting thing:
no b2b, direct asio recording... (fx4/5 direct to asio recording)
Totally failed with 1 off again for the lsb's, and the msb's completely incorrect...

this was no b2b module in the stream, and, afaik, it should have been an complete copy too... but it is 1 off?
and not to mention the lsb/msb thing...

More on this later though, with some screenshots

first have to adress something, wich I still never quite got a clear answer on...

To eliminate any possible error of the waveout devices, I tried to play it over directsound... problem though, all editors and players I have, don't support this, it's either wave, or asio, or the signal gets distorted... (cooledit = wave, foundry = wave, wavelabs = wave/asio, samplitude = wave/asio, and directsound players like winamp and such totally screwup the signal...
So, if anybody has an idea on a program wich actually can play waves perfectly over directs sound, let me know...

Now, next, I wanted to try to play it over asio... and here is the bug/issue/thing I never did get an clear answer on...
Is this possible? having one program play on asio, while another is recording...
Or to be exact.. is it possible to use multiple asio clients side by side? (possibly using eachothers outputs and inputs, but if not possible to have 2 output programs output on the same channel at the same time, then 1 program?
Used to work half, changed around every driver release, and some combo of programs did work, and didn't, even completely hanging the driver (or, as mentioned, Direct X? but I fail to see what that has to do with asio)
Vst hosts like spinaudio worked most of the time, sometimes with traktor, reason always seemed to be a problem, etc... etc... complete inconsitant behaveior... (and kinda annoying, cause I used to be able to run reason with traktor, and that never was possible anymore after 3528)

Anyways, it now failed, using samplitude as player and wavelabs as recorder, resulted in the error of too much latency, or something like that... (the error is mentioned on the forums numerous times)

Now, to get to the idea why b2b does work however, but there is a bug with it, with asio recording...

I decided to completely eliminate any play device problems, by using the wave generator... now, while I'm typing this, come to think of it, maybe this is completely useless (b2b, binary data coming out of the dsp, instead of inside it? is this thing to overcome the resampler procedures?) but here goes anyways, cause it does point to an asio bug...

setup for dsp:

first setup, direct path, no b2b, path to recL/R and asio...

second setup, b2b, path to recL/R and asio...

wavegenerator standard setup... (used square btw... maybe I should have used a phase thing or something though, to make the stereo more seperate...)

and finally, ultra edits output with the waves, generated by wavelab, on all 4 possible outputs... direct path rec L/R, direct asio, b2b RecL/R and b2b asio...
for rec I just took the wave 1/0 rec device ofcource
(offsetted them a bit to make it view easier)


As you can see, 3 wave files are the same, but 1 is again, 1 off...
this is the b2b to asio recording...
the recL/R IS correct however...

Now, My conclussion about all this...
I first of all, am kinda taken by the fact of the original wave files, not being able to be played correctly...
I'll try to do the same 4 wave recordings, I just did, however, now using an actual wave play...
as far as I know, then, direct path to asio, and to recL/R, should also give the exact adio back? or... wich I now again remember (aint minds wonderfull things... can't they just have all thoughts about a subject at the same time :-), all sound is being resampled by the life... b2b is here to prevent that...

hmz... k, letme change my conclussion, b2b does not work...
how I see it... the 4/5 wave device puts out the resampled data from the waves, so recording that, will give diffrent data with the original... (missed that step in my thinking)
b2b works, with making binary to binary copys of the data, so it will not be resampled...
however, as clearly seen in the previous post, and again with the tests i did now, the data I am getting is resampled...

now what the wave gen test showed, is another error, when having the b2b input connected with an dsp internal data source, (being it, an fx output, or the wave gen), and the output to an asio epilog, the data gets shifted by one... connecting to recR/L does however give the correct info... (little sidestep conclusion, to record AC3 data, use the wave recording, and not asio?)

so... b2b does not work I guess, and if it would work, then there is an asio recording bug with it...?
does this conclusion sound about rite?

Now, the last thing... maybe, I'm doing it all wrong all together... wouldn't surprise me :-) but I do think, I followed the correct guidlines?
If needed, I'm willing to give some kind of remote control thing to you, to maybe check it all yourself on my machine? Maybe that is an sollution if I am doing it wrong :-) (radmin thing)

(and again, my mind jumps in... I can do 1 other test, asio out, recL/R recording... will do that in a sec)
(k, edit, never mind this test... asio has no binary output thing at all I guess, now correct me i'm wong, but this would have no use rite?)

Eugene Gavrilov

well, a long report! thanks for your efforts!

anyway, let's clarify some points

Q: what is the b2b plugin needed for?.. [that is, 'The Theory Of 10k1/10k2 Resampling']

A: any data that gets into the card gets resampled. the card operates at 48000Hz, however, even if the input data is 16/48000, it gets resampled anyway
this happens for all the cards, APS, Live, Live5.1, Audigy, Audigy2 ...

after the data gets into the DSP, it can be routed to any output [as you probably know]
the DSP doesn't change/resample the data (unless you add some effects)

so, the main problem is to get the data unresampled into the DSP (which will output it to spdif/i2s outputs unmodified)

Q: what sources are resampled?

A: all wave/synth/asio and input sources are resampled
that is, your spdif-ins are resampled, too
that's why it is impossible to record, say, CDSPDIF or AC-3 data without modifications

Q: what else is resampled?

A: moreover, the recording data is resampled, too!
that is, if you get the data in the DSP and route it to the RecL & RecR pins of the epilog, it gets resampled before being recorded by the driver
this is a hardware feature that cannot be turned off

[note that the spdif inputs are resampled twice: first, when they get into the DSP; second, when they get into the driver buffers]

---

To summarize:
============
wave data gets resampled when it is played back (before it gets into the DSP)
spdif ins and other inputs are resampled before they get into the DSP, too
[unless you use 'Direct SPDIF Recording' available for 10k2-based boards -- this method bypasses the resamplers and the DSP]
spdif outs and other outputs are NOT resampled [unless you switch the spdif freq to 96000 or 44100]
-- because they are synchronized with the 10k1/10k2 chip by design
the DSP data been recorded passes thru the resamplers (RecL/RecR - winmm and directx recording)
(that is, -any- data you record via generic directx/winmm applications)
recording via ASIO is bit-to-bit [so, recording via ASIO records the DSP-processed data in unmodified form, but SPDIF inputs were already resampled before they get into the DSP]
============


the solutions:
==========
there are at least two methods to send the data to the DSP unmodified
for audigy-based cards: send it via b2b plugin, which corrects resampling errors (by some easy recalculations)
according to our information, all the 10k1-based cards with chip revision>=7 can turn the resampling off, too
but, unfortunately, we don't know how exactly

Testing methods:
=============
the mentioned above stuff defines the testing methods I've described in my first posting
the output should go thru b2b plugin and the recording should be done via ASIO
this records an -exact- bit-to-bit copy of the original WAV file
[the same happens if you record the data via 'Direct SPDIF Recording']

btw, even if the present 'b2b' plugin doesn't work, this doesn't mean that the passthru is impossible
perhaps, Lives simply have a different formula for restoring resampling data

/Eugene

P.S.
>> to Mata Hari
if you have Messanger/ICQ ID, pls send it via a private message

P.P.S.
the ASIO inputs are random due to a hardware 'feature' of all the '5.1' cards (asio1,2 are shared with 'center+lfe' in hardware)
we were unable to fix this issue

Mata Hari

well, your welcome :-)
thanx for clearing allot of this up btw! (have to remember that RecL/R also is resampled)

I might have some good news, wich maybe is allready known or not...

The linux 10k1 driver does have support for ac3 through, quickly glanzing the source of that tells me something like setting a reg thing on the live with a bunch of flags, then setting another 1 of 4 regs with some others or something...

If this is allready known, and had no use, then, disregard this post... if not, then maybe that is useable? (I'll try to reverse engineer the process a bit more clearly then, looking at it longer then 2 minutes :-)