Topic: 9632: Channel routing with kernel streaming

Hi everyone

Channel routing with 6 channel audio is behaving a bit strangely: The surround channels are going to the back channels instead of the side channels in my 7.1 setup. This is only happening in kernel streaming mode. In Wave Out or Direct Sound mode they go to the side channels as they should. I have the interleaved option turned on and I am using reclock to get kernel streaming (but reclock is also used for dsound and waveout).
Also, when playing back 7.1 material, all the channels are routed correctly, also in kstream mode.
I am using XP SP3 with the newest 3.074 WDM streaming driver.

Using the matrix to fix this is not really a good solution, because then I would have to use a different matrix every time I change from a 5.1 source to a 7.1 source.
I hope somebody can help me.

Here are two test files with which this behaviour can easily be tested in Windows Media Player.

6 channels:
http://www.megaupload.com/?d=T0D09T1A

8 channels:
http://www.megaupload.com/?d=GM455Z5I

Best regards

2

Re: 9632: Channel routing with kernel streaming

You have to select 5.1 channels in Windows speaker setup for correct 6 channel playback.

Regards
Matthias Carstens
RME

Re: 9632: Channel routing with kernel streaming

Hi and thanks for you answer.
It is set to 7.1 now. But I don't believe this is the problem, because the playback is as it should be in Direct Sound or Wave Out Mode.
The routing should behave the same way in kernel streaming mode, should it not?

Re: 9632: Channel routing with kernel streaming

Tried it. Setting Windows speaker setup to 5.1 has no effect. I can even set it to stereo, all stays exactly as described.

5

Re: 9632: Channel routing with kernel streaming

Ok, I did not understand that one correctly. Indeed we never tested this with Kernel streaming mode. We only test it via standard Media Player WDM playback.

How are you doing this? What is Reclock? Can you be sure the problem is not on the software side?

Regards
Matthias Carstens
RME

Re: 9632: Channel routing with kernel streaming

Well, this is Reclock.
Basically, it is a direct show audio renderer that syncronizes the clocks from soundcard and graphiccard in order to prevent micro stutters in video playback.
It can be set to load in place of the default audio renderer and you can choose if you want the audio to be played through Direct Sound, Wave Out or Kernel Streaming.
The last is of course a good idea to get lossless sound.
To be honest, I am not absolutely sure the problem is not caused by Reclock. But I can't check that because I need reclock to get Kernel Streaming in the first place.
However, Reclock should not do anything to the channel order, just pass it on. So I doubt it is at fault.
Would be great if you could find out what's going on here!

Re: 9632: Channel routing with kernel streaming

Unfortunately the new drivers don't help, either.
Some input would be much appreciated...

Re: 9632: Channel routing with kernel streaming

deathlord wrote:

Hi everyone

Channel routing with 6 channel audio is behaving a bit strangely: The surround channels are going to the back channels instead of the side channels in my 7.1 setup. This is only happening in kernel streaming mode. In Wave Out or Direct Sound mode they go to the side channels as they should. I have the interleaved option turned on and I am using reclock to get kernel streaming (but reclock is also used for dsound and waveout).
Also, when playing back 7.1 material, all the channels are routed correctly, also in kstream mode.
I am using XP SP3 with the newest 3.074 WDM streaming driver.

Using the matrix to fix this is not really a good solution, because then I would have to use a different matrix every time I change from a 5.1 source to a 7.1 source.
I hope somebody can help me.

Here are two test files with which this behaviour can easily be tested in Windows Media Player.

6 channels:
http://www.megaupload.com/?d=T0D09T1A

8 channels:
http://www.megaupload.com/?d=GM455Z5I

Best regards

Deathlord, The best solution is to use the older MME drivers, they sound great , can be used with almost no latency, & are accurate,
& have no WDM weird phenemonas like the one you describe & the best bit is you do not need reclock if all you try to get is bit perfect sound,
& not because of Film issues etc.

I did try these basic test files you linked with your card & latest firmware + 2.94(6) MME driver, & it works fine,
& it is a better sounding setup if you ask me, I had to do this move back to the older drivers on more then one occasion for all that got used to the older MME drivers performance & features.

The only catch is, 6 channel 2496 cannot be used on this card with these old drivers (Not sure about the new wdm ones),
as the channel wave id mapping starts with the Adat ports that will flip into SMUX mode & will not 'extend' for the remaining two or four channels to the SPDIF & AN 1+2 virtual outputs, so 6 channel 2496 playback is impossible on this card with the older drivers.
you can read about this issue here: http://rme-audio.de/forum/viewtopic.php?id=4192.

Re: 9632: Channel routing with kernel streaming

Hi Byt3

Thanks a lot for your testing.
I could easily live without 2496, that would be no problem.
However, channel routing does not work as it should for me with latest firmware and 2.94(6), I tested it yet again.
I get the very Problem described in what you quoted: with the 6 channel file, surround goes to back, compared to the 8 channel file. The only difference is, with 2.49(6) it happens in waveout, while in 3.x it happens only in kernel streaming. It happens independent of reclock (now I am absolutely sure, I can get waveout without reclock in some cases).

Are you *sure* the side channels from the 8 channel file are routed to the same place (speaker) as the surround channels from the 6 channel file?
E.g. can you hear "side left" spoken from the same speaker with both files?

Did you test waveout or direct sound?
I can't test direct sound with 6/8 channels (lack of "interleaved" option, get no output).

The thing is, RME *already solved the problem* for waveout in driver version 3.x, but it is still there with kernel streaming.

10 (edited by Byt3 2009-06-02 01:43:48)

Re: 9632: Channel routing with kernel streaming

No not to the same Chans, I assumed it is the way these files are mapped (?), [disregard, I Realized files are fine after checking again]
In the 6 Chan File Side LR is on channels 56, & in the 8 Chan File it's on 78.

(about the 2496, I feel that living without at least 6 channel 2496 downmix ability on a card at this level & price, where any pos card can do it in this Blueray age is unacceptable).

Just did a test on another clients machine for you, This time using WDM with a Fireface, Where Side LR is always on 7+8.

EDIT:
You are right, The Channel mapping in the 9632's Driver is wrong, I never noticed it because I rarely come across 7.1 material.

Re: 9632: Channel routing with kernel streaming

Byt3 wrote:

(about the 2496, I feel that living without at least 6 channel 2496 downmix ability on a card at this level & price, where any pos card can do it in this Blueray age is unacceptable).

No argument there. I just don't need it personally, so I would be willing to stick with the old driver if it actually solved my problem.

Byt3 wrote:

[/b] You are right, The Channel mapping in the 9632's Driver is wrong

Thank you very much for confirming.

Re: 9632: Channel routing with kernel streaming

Hi again

Any chance this obvious, severe (but easy to fix;-)) bug is going to be removed in the new year?

It persists in Vista and Windows 7 using WASAPI (instead of kernel streaming).

It can also very easily be tested using foobar2000 and the kernel streaming plugin.
Playing the 5.1 file *without* the plugin gives *correct* routing.
Playing the 5.1 file with the plugin active gives *wrong* routing.
(The "interleaved" option has to be checked and ADAT1+2 has to be selected as playback device in foobar.)

Still hoping...

Re: 9632: Channel routing with kernel streaming

Which driver version are you referring to?


Regards
Daniel Fuchs
RME

Regards
Daniel Fuchs
RME

Re: 9632: Channel routing with kernel streaming

The newest WDM driver, 3082.

It happend with older driver versions, too (all the WDM drivers where ks worked). (With the old PnP drivers the routing is also wrong in waveout, not just in ks, if I recall correctly.)

Re: 9632: Channel routing with kernel streaming

MC wrote:

The new Windows driver 3.083, floating within this forum for some time, has now been released on our website. Please note the date. Early downloaders might want to update to this version which is dated 02/19. Fixes:

[...]
- WDM: Analog DVD multi-channel playback via Loudspeaker device (change loudspeaker configuration to 5.1 or 7.1)

I do not quite understand what this means, but it sure doesn't help here, i.e. same problem with 2083...

Re: 9632: Channel routing with kernel streaming

2084, still nothing.
RME, what are you doing?

Re: 9632: Channel routing with kernel streaming

Just moved to Windows 7. Same story. Wait, not quite.

NOW NOT EVEN WAVEOUT WORKS ANYMORE!!!

*Both* waveout and WASAPI exclusive get a wrong channel mappig with interleaved option for 5.1/7.1 channels.
(Interleaved does not work for direct sound at all, driver 3085: nothing new.)

How is this even possible? Until now we could get around this by using waveout. Not anymore!
It's been almost two years since I started this thread. Where is the problem?

Re: 9632: Channel routing with kernel streaming

I hear you.
It has been two years for you maybe ..
just read my older posts requests  & explanations, for both firefaces & hdsps, nothing got done on these matters,
quite the opposite, for years now .. so ..

in any case, Of course I join you &  support your request.

Re: 9632: Channel routing with kernel streaming

Byt3 wrote:

in any case, Of course I join you &  support your request.

Thanks for that!

Re: 9632: Channel routing with kernel streaming

Interesting observation:

There is an ASIO plugin for foobar2k: http://www.foobar2000.org/components/view/foo_out_asio
With it, one can explicitely map each channel for multi channel playback seperately. This means, the interleaved option is not needed.
And it also gives the same wrong/inconsistent channel mapping! This means we can rule out the interleaved option as the source for the problem. When an 8 channel file is played, everything is fine. When a 6 channel file is played, something screws up the channels.

I really expect a statement from RME here. How can they just ignore such an issue???

21 (edited by deathlord 2011-04-29 14:34:58)

Re: 9632: Channel routing with kernel streaming

All right...

The 5.1/7.1 channel swapping problem can be solved in direct show players by using the auto-loading presets feature found in ffdshow audio processor.

Win7x64
MPC HC 1.5.1.2903
ffdshow tryouts 3184
madFlac 1.10
ReClock 1.8.7.3
Haali Media Splitter 03/03/2011 (for flac in mkv container)

- disable all internal filters in MPC
- go to external filters, add and prefer:
- Haali Media Splitter (AR)
- madFlac Decoder
- madFlac Source
- ffdshow audio processor
- double click on ffdshow audio processor
- go to codecs, make sure it says Uncompressed: all supported
- go to Profiles/Preset settings
- Add a new Preset named "8_Channel"
- double click on it to activate it
- open Preset autoload conditions
- activate "on number of channels match", enter "8", close the window
- activate Automatic preset loading at the bottom
- go to Swap channels, activate it
- set it to swap side to back
- press ok

Now the Preset "8_Channel" should load automatically whenever an 8 channel source is played.
You can check if it is loaded: During playback, go to Play->Filters->ffdshow Audio Processor->Properties->Profiles/Preset settings
where the active preset is shown at the top.

Re: 9632: Channel routing with kernel streaming

ahh DeathLord,
Had I known you are looking for this kind of filter chain solution I would have advised you to do this ages ago, assumed you are not after a filter chain solution for this level of a card,
so I never mentioned it.
Thanks for sharing the info, all the best.