Scope 4.0 Wave driver + Wave Source module questions

[Dstruct]

Is it correct that you can't set the prefered bit depth for the wave driver in the device manager on Windows XP? Here the setting is "greyed out" and "16bit" is selected. I guess it's because of WDM drivers which do all this stuff behind the scenes? But are the Scope drivers WDM drivers? I'm not sure in this because in the manual I couldn't find anything related to this. They just show how to set the preferences. But on our system we can't change them!?


2nd "problem": Using the 24bit wave source doesn't work properly here. Using it with foobar2000 isn't as "smooth" as when using the standard wave source module. The issue occurs when you stop playback. With the 24bit wave source module you can hear some glitches when stopping playback (buffers not cleared properly or so). Just curious. I'm just using the standard wave source module for now. With this, stopping playback is instant and without any glitches.

[garyb]

no, you can't set bit depth in windows. Scope is not a windows soundcard. bitdepth is determined by the module used.

24bit wave modules are ok here with samplitude, media player, flash media encoder, pinnacle 10, magix audio studio and a number of other programs. it's possible that there's a problem with the 24bit module and foobar, but i think there were a few users who reported success with that app. there may be other issues in the system.

[Dstruct]

no, you can't set bit depth in windows.

Go to the device manager -> Pulsar2 (or whatever) -> properties => now there you should see what I mean. It's even explained in the manual. Why is this setting "greyed out" so that you can't set the bitdepth? Why is it displayed if there's no use for it?

My RME HDSP card for example is also not a "windows soundcard" as you call it. But there I also don't have such cryptic setting tabs.

[valis]

It's a setting that no longer applies, hence why it's greyed out. I do believe this is mentioned somewhere in the manual or documentation (legacy feature), and garyb is correct about using the i/o right module to set bit-depth.

As for why foobar2000 'clicks', that's because when you hit stop that's where the buffer from foobar2000 ended (a non-0 value). Scope's drivers don't (and shouldn't) perform a 'fade' when an application stops sending data. That's for the application to do.

You might want to check foobar2000's Output settings (File>preferences>Playback>Output) and insure it's also set to 24bit there, increase the buffer size if necessary (unlike audio applications, a media playback application should have relatively HIGH buffer settings to keep cpu load down and insure it functions without problems). This is a client-side buffer, where it fills up a 'bucket' for data before it's sent to the Scope soundcard. Ie, it's in *addition* to Scope's latency setting (ULLI) which determines the size of the buffer(s) actually sent to Scope's Wav output modules. You might also want to consider increasing your ULLI when not doing music (ie, if you use 7ms for production that's probably a bit low for casual listening).

Then go under 'Advanced' while still in foobar's preferences, and notice there's a few "Fading" settings under 'Playback'. 100ms has always been sufficient here...

And on the RME, this is what my settings panel looks like:



While I wouldn't call either 'cryptic' to a user that's familiar with what the settings mean, I would say the RME is more complicated 'looking' than even Scope's.

[Dstruct]

It's a setting that no longer applies, hence why it's greyed out. I do believe this is mentioned somewhere in the manual or documentation (legacy feature)

That's what I wanted to know. Thanks! One could think the card is running at 16bit without the possibility to change it when looking at this tab.

As for why foobar2000 'clicks', that's because when you hit stop that's where the buffer from foobar2000 ended (a non-0 value). Scope's drivers don't (and shouldn't) perform a 'fade' when an application stops sending data. That's for the application to do.

On my RME card there's no such problem. I guess the Scope Wave drivers are MME rather than WDM. Foobar2000 just has DirectSound (WDM) output so this could be the reason. I'm not sure. And why does it work fine with the standard wave source module then? Strange.

You might want to check foobar2000's Output settings (File>preferences>Playback>Output) and insure it's also set to 24bit there, increase the buffer size if necessary (unlike audio applications, a media playback application should have relatively HIGH buffer settings to keep cpu load down and insure it functions without problems). This is a client-side buffer, where it fills up a 'bucket' for data before it's sent to the Scope soundcard. Ie, it's in *addition* to Scope's latency setting (ULLI) which determines the size of the buffer(s) actually sent to Scope's Wav output modules. You might also want to consider increasing your ULLI when not doing music (ie, if you use 7ms for production that's probably a bit low for casual listening).

Then go under 'Advanced' while still in foobar's preferences, and notice there's a few "Fading" settings under 'Playback'. 100ms has always been sufficient here...

I know how to configure Foobar2000 and I'm also not new to these things. I'm just new to Scope. None of the Foobar2000 settings solve the problem with the 24bit module. Small differences can be heard but the problem doesn't go away no matter which bitdepth chosen or how long you set the fade out!

And on the RME, this is what my settings panel looks like:



While I wouldn't call either 'cryptic' to a user that's familiar with what the settings mean, I would say the RME is more complicated 'looking' than even Scope's.

Hey looks similar to mine

I don't need fancy GUIs. RME do a great job on their drivers. Close to perfect.

[valis]

I know how to configure Foobar2000 and I'm also not new to these things. I'm just new to Scope. None of the Foobar2000 settings solve the problem with the 24bit module. Small differences can be heard but the problem doesn't go away no matter which bitdepth chosen or how long you set the fade out!

I've no way to know what's in your head. Giving instructions is meant to be helpful not condescending, just fyi.

It's possible that the drivers are still MME, but I seem to recall they work with some versions of Sonar (and Acid) better than the ASIO drivers so that muddies that picture a bit. I used to have a utility that showed driver details somewhere but I can't recall offhand which one it is (it's not Rightmark I don't think). Someone with access to Visual studio could write up a quick routine to probe it, but honestly I don't even use Scope's wav drivers very often.

As for the RME, I quite like mine too. I like Scope as well, and just realized a while back I'm happier with it in my secondary PC connected to my RME via ADAT & AES, since having 2 soundcards is somewhat redundant. Between them and my analog mixer I can create routing schemes that weren't possible in a home studio when I started doing electronic music. However the RME by itself is just a soundcard, and I don't use TotalMix for anything but routing here... (aside from headphones out everything is either off or at nominal/0dBf). Scope covers quite a few uses for me here (send/returns for my board, digital send/returns via ADAT/AES, digital mixing possibilities, synths). Now that I know Scope very well, I actually find that I use it for (on a typical production) 2 send/returns from/to my analog mixer, 1 stereo digital send (returned to my board's analog returns) and then a few really great 'stems'. Stems like stacked synths with lots of complicated parallel processing, or perhaps a drum bus mix with some engineering, effects, mixing and then bus compression at the end, perhaps a huge modular creation that is output via multiple outputs and layered with another part....

If you've got Scope & RME in the same box, then you should have a plethora of output drivers at your disposal and hopefully some way to sum them before hitting your monitors. Scope isn't without flaws but if you play off its strengths and are aware of its weaknesses imo it's quite a handy & powerful set of tools. You seem to be doing a great job at identifying weaknesses so far...looking forward to seeing you post up some discoveries in the other direction too.

[Mr Arkadin]

You seem to be doing a great job at identifying weaknesses so far...looking forward to seeing you post up some discoveries in the other direction too.

i'm not holding my breath on that one. Maybe if his name was Cnstruct things would turn out a whole lot more positively.

[Dstruct]

Exactly.

[garyb]

have your fun, but please don't make your living as a troll. there's no need for it to get ugly.

[Dstruct]

Who's getting ugly?

[voidar]

From my tests, both wave modules truncate to 16-bit which pretty much reflects what the driver window says.

[Dstruct]

That's right.


And: It's the same in Scope 5.x


Top notch drivers. Don't know what these guys at Sonic Core are doing.

[Sounddesigner]

From my tests, both wave modules truncate to 16-bit which pretty much reflects what the driver window says.

If true then this sounds like a bug you should report to Sonic Core. There is suppose to be both 16bit and 24bit Wave/Asio options (32bit Asio also). The 24 bit Wave module is suppose to be as its name says, and is listed in the manual as 24bit resolution. If truncation is occuring with the 24bit Wave module then this should be reported to Sonic Core because it would no longer be performing in accordance to its name, definitely making some sort of bug be the problem.

EDITED

[Sounddesigner]

That's right.


And: It's the same in Scope 5.x


Top notch drivers. Don't know what these guys at Sonic Core are doing.

Are you looking for answers/solutions or are you looking to take cheap shots at Sonic Core? You seem to be confirming the suspicions of other posters in this thread who believed you where out to troll. Your last two sentences seem like cheap attacks to me.

The RME Drivers is not always without flaws, here's the link to a thread where only recently was a person in this thread even able to use WDM/KS due to the recent update RME released about a week ago - http://forum.cakewalk.com/tm.aspx?m=2075905

[Fluxpod]

Atleast rme is fixing the bugs in a reasonable timeframe.

[Sounddesigner]

Atleast rme is fixing the bugs in a reasonable timeframe.

I can't argue much with that cause i do wish S|C's development would speed up. But if S|C is simply doing what they can as fast as they can i can't complain much either, late is better then never, and never was the prospect not too long ago. Hopefully S|C will grow and things will change regarding development pace.

Is it even fair comparison with RME's fast updates and Sonic Core's slow ones since Sonic Core's scope platform is by FAAAAR more complex to develope for then RME's products wich are soundcards only? A better comparison would be SCOPE and Protools, Protools is still in beta with their 64bit drivers and have been for awhile now and have been very slow with software and hardware updates aswell. Avid is a far larger company then S|C and even Avid can't move too quick. TC Powercore and Soundscape are slow with software/hardware updates/upgrades aswell, not a strange coincidence since all are complex dsp platforms.

I mentioned RME in my last post cause the OP speaks so highly of them and seems to act as if only S|C's drivers have problems. My point is driver problems are common and bugs are common when dealing with complex computer related products.

In the OP's situation with scope drivers; if a bug is present then maybe the OP should've reported it long ago rather then just complain? Sonic Core may be slow but they also can't fix what they don't know about (assuming a bug is present).


EDITED

[Fluxpod]

Late is not better then never.Late is late!
Ive been with this plattform for 10 years and ive been "lated"more then once.They just need to stop beeing late and silent.Thats all i am asking.I dont even use the asio drivers.Procastinating or beeing late wont get you far by todays standart.Its not a good idea treating the plattform like they do now.They need more developers to bring it up to todays task ASAP.There is no way around it and no talk that can solve it.
Bring sfp 5.1 with BUGFIXES important stuff like midi sync and cc remapping.
Really.

[t_tangent]

Just a quick reply in case you never managed to solve that issue when using the wave drivers. I had similar issues with Winamp and Foobar at one point and I remember sorting it out as follows

1. Add a second Wave Source and or Dest module in the Project window.

2. In Foobar select this second Wave Output or input instead of the first one. As far as I remember this fixed the glitching. Not sure whay this is the case but I guess it has something to do with the way Windows audio drivers somehow 'interfers' with the first wave module, so adding a second Wave module frees up this 'interference'.

Give it a try and let us know if it works for you.

Cheers

[voidar]

If true then this sounds like a bug you should report to Sonic Core. There is suppose to be both 16bit and 24bit Wave/Asio options (32bit Asio also). The 24 bit Wave module is suppose to be as its name says, and is listed in the manual as 24bit resolution. If truncation is occuring with the 24bit Wave module then this should be reported to Sonic Core because it would no longer be performing in accordance to its name, definitely making some sort of bug be the problem.

EDITED

Done.

I just had to do some more tests and recheck my recheck.

You can all test this yourselves.

Have some suitable application output a -100dB signal to a Wave 24 module. Use any meter in Scope. Compare with a Scope generated low-level signal.

Only the source module seems to be affected. I.e. you can still record a 24-bit signal (i.e. mixdown).

[Sounddesigner]

Sounds like a great find and confirmation by you! Hopefully S|C will confirm and fix it ASAP. Only the 64bit beta for SCOPE was just released so there's a chance the fix can come soon in the next Official Update i'd imagine. Hope so.