Topic: hdsp asio VS cubase's control room steinberg bug; driver rollback?

caused by what appears to be a steinberg bug (as they usually are), a signal peaking @ 0dBFS (brickwall-limited with zero overs, with the 2bus fader set to unity) somehow translates to a signal modulating about 2dB higher once it reaches the 'control room' chain. no 'double-bussing' is happening by the way.

i came across a claim this is an interaction with the rme drivers specifically.

would a roll-back to a previous version of the driver help in this case? (which version?)

is there another workaround?

thank you.

rme hdsp [pci] / multiface II / win7 x64 / i7 4930k

2

Re: hdsp asio VS cubase's control room steinberg bug; driver rollback?

What exactly is the 'Control Room chain'?

Regards
Matthias Carstens
RME

3 (edited by beeski 2014-07-17 12:36:53)

Re: hdsp asio VS cubase's control room steinberg bug; driver rollback?

MC wrote:

What exactly is the 'Control Room chain'?

'control room' is another gain staging layer after cubase/nuendo's final 2bus, and is mainly designed to be able to quickly re-route the signal to different outputs of an audio interface (for fast switching of studio monitors etc). it also however features insert slots for VST plugins, so one can for instance place frequency analysers, room correction software etc.. (none of these inserted plugins get printed when an internal export / bounce is performed from withing the DAW application).

anyhow, here's the signal flow, as far as i'm concerned--

--the DAW architecture is 32bit float throughout the application, until the master bus' 6th insert, that is.
--after that, if the 'control room' feature is off, it becomes 24/16bit and is routed to whichever output busses are set up in the application.
--if the 'control room' feature is on, then after the master bus, the signal is routed further to the 'control room' bus, which allows to quickly change [which pair of outputs/speakers] the signal will be routed to; it also offers more VST insert slots.

now, at the last insert of the master bus, your signal is modulating at a maximum of 0dBFS (it cannot be any louder anyway, because -- as outlined above -- the 32bit-float architecture is cut off at the master bus fader). however, by the time the signal arrives at the 1st insert of the 'control room' (if the 'control room' is enabled), it modulates at >0dBFS (all faders are at unity). why does this concern RME at all? i wonder myself as well, but while scouring the internet for some info on the issue, i found claims this happens exclusively with cubendo VS an RME driver (although i don't know how that is possible).

rme hdsp [pci] / multiface II / win7 x64 / i7 4930k

4

Re: hdsp asio VS cubase's control room steinberg bug; driver rollback?

There seems to be some misunderstanding. The RME interface gets the signal at the very end. It doesn't know anything about additional control room or VST inserts. Therefore it is not 'our signal', but still Cubase' signal.

Regards
Matthias Carstens
RME

Re: hdsp asio VS cubase's control room steinberg bug; driver rollback?

MC wrote:

There seems to be some misunderstanding. The RME interface gets the signal at the very end. It doesn't know anything about additional control room or VST inserts. Therefore it is not 'our signal', but still Cubase' signal.

that was my logic too.

i don't know how someone attributed it to RME. i will try to find those posts again though...

thank you.

rme hdsp [pci] / multiface II / win7 x64 / i7 4930k