Jump to content

Major problems with Samplitude7 and Creamware


Guest Tobben
 Share

Recommended Posts

There seems to be some severe communication issues between Samp7 and Creamware

drivers, both ASIO and WDM. I've been trying to get this to work properly

for two weeks, recording approximately 20 000 tracks to pinpoint the errors.

I've tried Win98SE, WinME, WinXP Pro and all available Creamware drivers on

two different systems.

My main system: 2,4 Ghz P4(533 FSB), 1 GB DDR 2700 RAM, Abit BE7, Matrox

G450 and WinXP Pro. Pulsar II soundcard with RME ADI-8 AE converters.

When recording with ASIO drivers, 25-30% of the tracks are delayed by the

same amount of latency that the Creamware drivers are set to use.

If Scope Fusion Platform (Pulsar's software) is set to 256 samples latency,

Samp delays some of the recorded objects by 256 samples. If I set the latency

to 1024 in SFP, some tracks are always delayed by 1024 samples in Samp.

Recording Offset is set properly in Samp to get sample accurate recording.

Everything is measured by generating a sinus tone on track one in Samp. Track

one is routed through SFP back to Samp and recorded to the remaining tracks

in the VIP. (Mostly 8, 12 and 16 track VIP's) I've tried ASIO, ASIO2 and

WDM drivers with 16, 24 and 32 bit communication but everything fails.

It seems to me that Samp is simply not capable of separating the ASIO and WDM

drivers. I base this on the fact that I need to load 4 *WDM* drivers in order

to get 12 stereo *ASIO* tracks in Samp that are "recordable".

If I don't load any WDM drivers at all, Samp refuses to start. If I load one

WDM driver, I get 3 stereo ASIO tracks in Samp. Samp detects all the ASIO

outputs from SFP just fine, but I can only record 3 stereo tracks for each

WDM driver. If I load 1 WDM driver and try to use the 4th ASIO recording

device, nothing happens. I only get the following message in the status bar:

"OpenAIU: Unit is open". <_<

Instead of writing a huge list of what I've tried regarding settings in Samp,

trashing ini-files, OS tweaks and the likes, I'll just mention that Samp 6.05

works fine in Win98SE with MME drivers...*AND* I don't experience any of these

problems when using the demo of Cubase SX!!!

Any help/advice is very much appreciated! Undocumented settings, registry

tweaks... I'm prepared to try everything...

Best regards,

Tobben

Link to comment
Share on other sites

If I don't load any WDM drivers at all, Samp refuses to start.

I don't understand this point. I have not made all the testing you've done, but this afternoon I opened several times Samplitude Professional 7 (registered) with an SFP project that uses ASIO2-flt Source and Dest 64; with:

- 16 inputs ASIO2-flt Source 64, and

- 32 outputs ASIO2-flt Dest 64

Opening Samplitude with this SFP project has perfectly worked with not a single crash or failure. On an Athlon 700 Slot A system, in Windows XP.

I have not recorded as much tracks as you've done, so for now this is the only thing I can write here. It may lead to the conclusion that there is something wrong in your installation (?) but infortunately I can't help you more right now

My setup: Athlon 700 Slot A, 768 MB PC100 SDRam, Pulsar 1 + SRB 1 + Luna with SFP 3.1c (= 11 Sharcs in 3 PCI slots)

Link to comment
Share on other sites

Hi Grok,

Thanks for your reply!

I guess I wasn't clear on the WDM driver. I'm talking about the amount of wave devices that you specify in

Device Manager > Pulsar dialog box, not the SFP project. If you set this to 0, Samp refuses to start.

That's no big deal really.. what's worse is that I only get 3 functional ASIO stereo input/record devices in

Samp for each wave device, and that the recorded objects are randomly delayed. The delay appears with

random intervals, but the delay are always matching SFP's latency (ULLI) settings. Or more correctly, it matches what Samp reads from SFP. (Example: ULLI @ 7ms/44.1 Khz = 256 samples in Samplitude)

I'd be very greatful if you could do the following (very easy) test:

Set the number of wave devices in Device Manager to 1, reboot and open the SFP project you mentioned.

In Samp you'll have 16 ASIO stereo devices according to SFP's 32 outputs ASIO2-flt Dest 64.

Now, try to record something on record device 14, 15 and 16 in Samplitude....I'd guess that you won't be

able to record anything except on input 1,2 and 3.

Believe me, I'd love to be wrong here as it would've been far easier for me to fix a faulty setup. However,

I've tried it on two pc's, three operating systems and everything is installed from scratch. I've tried XP in

both Standard PC and ACPI mode, I've tried Pulsar II and PowerSampler together and one by one. I don't

have any other PCI cards but I tried all available PCI slots, unfortunately with no luck at all.

Best regards,

Tobben

Link to comment
Share on other sites

Thanks Volker!! I *really* appreciate that.

It's rare to see this kind of response from developers these days!

I just uploaded some screenshots of Samp, Pulsar and various registry entries on my homepage.

http://home.broadpark.no/~tobben/

I doubt that this will help solving the problem, but it might be easier to get an overview...

Thanks again!

Regards,

Tobben

Link to comment
Share on other sites

Guest Kim Kristensen

It is well known that creamware until now didn´t develope good WDM drivers for XP (the wave drivers for win98 work),but their ASIO drivers work good.I had to give samplitude a break though I like the program a lot until creamware make up their mind.

Kim

Link to comment
Share on other sites

I'd be very greatful if you could do the following (very easy) test:

Set the number of wave devices in Device Manager to 1, reboot and open the SFP project you mentioned.

In Samp you'll have 16 ASIO stereo devices according to SFP's 32 outputs ASIO2-flt Dest 64.

Now, try to record something on record device 14, 15 and 16 in Samplitude....I'd guess that you won't be

able to record anything except on input 1,2 and 3.

Best regards,

Tobben

Test done: with the number of wave devices set to 0 in the Device Manager, Samplitude doesn't start

with the number of wave devices set to 1 in the Device Manager, I was not able to record a single track, neither with ASIO (1+2) nor ASIO (14+15), ...etc...

I have put the number of wave devices to 32 in the Device Manager as it was before, and tried to re-record a single rimshot waveform;

-with the STM1632 console, ULLI at 12ms 48 kHz, ASIO2-flt 64; I had to set the recording offset in Samplitude to 138 samples; made few recording with this offset; the resulting waveform was in synchro each time I recorded BUT has a lower level than the original (everything set to 0dB in Samplitude and in SFP) and the waveform resulting was slightly different. Increasing the Samplitude's mixer output with the corresponding dB has not given a corresponding increase in the resulting recorded waveform, and this waveform was also slightly different than the original

-without any Creamware SFP's console but only puting the ASIO(1+2) SFP's input in the ASIO(3+4) SFP's output and recording: there was also a difference in level and in form in the recorded wave. I had to put the recorded offset in Samplitude to 130 samples in this case to have both original and recorded waves synchro

This little testing in Windows XP has took me few hours and I had stopped there. The recorded waveform was not a single time equal to the original waveform. I really don't know what to think about that.

I have not made a such big testing as you've done, Tobben. With an offset of 138 samples (with the STM1632 console) and then an offset of 130 (without any console) and an ULLI of 12ms at 48kHz, the few recordings I've made was synchros, but it was only from one track to one another track, and not with several tracks as you've made.

I am disapointed to have seen systematically the same differences between the original track and the recorded one. Tried to improve that, but no way. I don't have others soundcards to see if it goes differently with them. The results I had were not what I thought numerical fidelity is...

Maybe testing with only one percussive sound is better than testing with a sinus; maybe it shows others things.

I'll try to do multitrack recording later; today it has give me "unexcpected DSP overload" so I stopped trying multitrack recording and felt in the topic I write here :(<_< I'll do it again with others SFP projects.

Have you tried in 98SE, Tobben?

Link to comment
Share on other sites

I agree Kim,

Creamware's WDM drivers are crappy....and I wouldn't be surprised if they are the cause of the random

delays in Samp when recording with ASIO. Personally I'll skip Creamware before I give up on Samplitude.

However, I believe that the solution for proper ASIO recording is to stop Samp from being dependent on

Creamware's WDM drivers.

Maybe a new entry in Sam7_E.ini, something like:

[Factors]

SkipCreamwareWDM=1 <_<

Regards,

Tobben

Link to comment
Share on other sites

Thanks a lot for the testing and your feedback, Grok!

Some parts of your results was a bit surprising to me, especially the levels/waveforms.

I'm gonna try 48 Khz with a percussive sound and see how that turns out.

The offset is similar to mine. I get 136 with Pulsar2 only, and 144 with Pulsar and PowerSampler.

The fact that you didn't get any delays could be a coinicidence. I've sometimes recorded somewhere between

40-50 tracks before the delay starts to kick in with random intervals.

I'm pretty sure that the recordings will be as perfect as they can be if it's possible to avoid Samp's ASIO/Wave

"mixing". I've never heard a software that matches Samp when it comes to sonic quality.

I'll do some more tests and come back with a report.

Regards,

Tobben

PS: Yes, I did some short tests with Win98SE, but I skipped it once I experienced the same delay problems.

Link to comment
Share on other sites

A little update:

Grok, I recorded 4x12 rimshot tracks in 48 Khz, ASIO 32 flt, STM1632 (direct out) but the tracks seemed

more or less perfect to me. (Except that 2 tracks were delayed)

The only variations I could detect was on the last track. The amount of difference in the waveform was similar

to track 12 on my screenshots.

I discovered a strange thing though... the last track in the view always has some small variations. If I zoom in until there are 4 out of 12 tracks visible, the last one is slightly different from the others. When I scroll trough the tracks, the waveform difference follows the last viewable track, and the track that I thought was different is suddenly correct when it's moved away from the last track slot.

Everything seems fine with 2 visible tracks, but once I have 3 or more tracks visible the last track is slightly

different. Possibly a tiny graphical bug?

I'm a little puzzled by the level variations you get. I've not experienced that when I have everything at unity

gain, no compressors etc. Strange...

Regarding the delays:

I recorded 200+ new tracks with ULLI @ 13 ms latency and 30 of them were out of time.

Then I recorded 200+ tracks once more, this time without rec monitoring and only 4 tracks were out of time.

I knew that the latency settings has an impact on the delays, but i didn't know that rec monitoring on/off makes such a big difference.

Regards,

Tobben

Link to comment
Share on other sites

A little update:

...

I'm a little puzzled by the level variations you get. I've not experienced that when I have everything at unity

gain, no compressors etc. Strange...

...

Regards,

Tobben

I think I understood now what is going on...

Made the same rimshot re-recording, but this time with two successive equals rimshots instead of one only in my first try.

The first rimshot is at time: zero sample; the second is one 1/4 second later.

In the recorded resulting track, the first rimshot is modified in level and waveform. The second one has the same volume and quasi equal waveform than the original (very little visible differences exists on some samples of the recorded second rimshot; is it a real differences or a graphic bug, I don't know. If these are real differences, they are very very small, and I guess they are non audible. It remains questionning anyway... <_< ).

With the first recorded rimshot, I see differences in the original and the recorded waveform in the timespace: zero to one hundred samples approximatively; after this timespace the situation returns to the normality.

So here is my conclusion: I guess there is a kind of automatic very quick fade in when recording with Samplitude Professional 7, Creamware's Scope Fusion Platform and ASIO2 32 bit float. This very quick fade in (approximatively 0 to 100 samples) is not an issue in normal recording situations. :(

Cheers,

Link to comment
Share on other sites

More testing...:

Recorded 64 stereo tracks, 32 bit float with Creamware's ASIO2 32 bit float drivers, 48 kHz. SFP's mixer STM 2448 with phase compensator, taking direct outputs. Recording offset set to 134 samples for perfect synchronization.

Recording made in 4 times, 16 stereo tracks recorded each time.

The sound came from ASIO2-flt SFP's intput (1+2), dispatched in 16 STM2448 stereo channels.

Result: all the 64 recorded tracks in perfect synchro except the 4 tracks recorded with ASIO2-flt SFP's (1+2) output, wich are delayed by an amount of 2 samples.

The "Unexpected DSP overload" that I had the first day was solved by puting the "Output preload" to the max in the Device Manager for my Creamware's cards. The first day, it was set to medium.

Link to comment
Share on other sites

A little different testing...

17 stereo tracks recorded successively one by one.

Each recorded track was then muted in the Samplitude's track parameter, to the left.

SFP project with ASIO2-flt drivers and STM1632

Monitoring Model: Manual Monitoring

Monitoring Mode : Hardware Monitoring

Results: Take10 and Take17 are delayed by an amount of 1024 samples; ULLI setting was 12ms at 48kHz (=13ms at 44,1kHz)

The "Stop" recording button has not respond properly in takes 12, 13, 15, 16 and 17; I had to wait from one minute to two minutes for the recording to stop.

Conclusion: there is a communication problem between Samplitude Professional 7 and Creamware's SFP...I saw the same error you've seen, Tobben. <_< I'll have to be careful with my recordings until this issue will be fixed

Regards,

Link to comment
Share on other sites

Hi again Grok,

Thanks a lot for doing these tests!

There's definately a timing/communication issue between Samp and SFP, and it

becomes much worse when using rec monitoring in Samp.

I've posted my findings on the SEK'D newsgroup also, and this morning someone

confirmed that there are timing issues with RME Hammerfall 9652 as well.

Regarding your level and waveform problems on the beginning of your takes:

You probably have "Auto Crossfade Mode" on. Take a look in the toolbar and see

if the icon/button is activated.

I'm sure Volker and the other developers will find this bug and crush it properly

now that they know it's there. <_<

Regards,

Tobben

Link to comment
Share on other sites

Regarding your level and waveform problems on the beginning of your takes:

You probably have "Auto Crossfade Mode" on. Take a look in the toolbar and see

if the icon/button is activated.  

Regards,

Tobben

No, it is not an "Auto Crossfade Mode" issue...

My thought is that it is not a real problem but a kind of hyper quick fade in (100 samples, it's very quick), a kind of security to avoid frontwaves that could damage speakers when playing recorded tracks...(?)

Cheers,

Grok

Link to comment
Share on other sites

Hello,

some observations with a mixed Pulsar 1+2 system,

Software-Version 3.1c, Win98 and WinXP ASIO:

-There really was a bug causing the usable ASIO channels

to be dependent on the available wave device number,

we've put the fix in the 7.01 patch, it now also starts

without wave devices present

-the offset really seems to vary sometimes between recordings,

but I've not seen a difference between the channels, all had the

same delay for one recording. Further to be investigated.

-For differences in the levels you should carefully check your

monitoring settings in Samplitude, I've easily run into

monitoring loops during testing.

Regards,

Volker

Link to comment
Share on other sites

Thanks a lot for the quick feedback, Volker. Much appreciated!!

Did you notice any difference at all regarding the offset problem after fixing the wave device dependency?

You've probably read it several times already, but I noticed a big improvement when switching off

rec monitoring in Samplitude.

Best regards,

Tobben

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...