It sounds like a simple routing issue. I don’t see the inconsistency that you are describing. Perhaps the best way to handle this is to call an Application Specialist at Yamaha Customer Support.

The audio your friends may be hearing could be leakage from your headset mic...
I don’t have a Windows computer convenient enough to duplicate your setup.

I apologize for my sub-par job in demonstrating what I am finding confusing.

When I check 'Listen to this device' in the Windows settings, the microphone's audio is routed to system output. When I listen to music in Chrome, it is played through system output. Therefore the inconsistency lies in the fact that I have one element of system output (the microphone) looping back to system input (via XS), whereas another element (the music) is not doing so.

The music heard by my friends could not have come from my microphone, as the XS was erroneously selected as my input device rather than my USB adapter (headset microphone). Once I switched to the mic, they no longer heard music.

I'll have a try with Yamaha CS.

In the meantime, if you don't mind, I'd like to see if I can resolve some of my confusion here by taking a different tack:

When the XS is operating as system audio interface via YSFW, is there a way to purposefully route the system audio received by the XS back out to the computer?

If you Return audio from your computer to the Motif XS via FW, you can select one of three pairs of audio returns.

Returns 1 and 2 go to Main L&R Outputs
Returns 3 and 4 go to the FW L&R Outputs
Returns 5 and 6 go to the Asgn L&R Outputs

You want to set you windows return to the 1&2 this will allow the computer audio to be heard through the main Outputs of your XS.
If you set the return to 3&4 this will arrive in the XS’s internal mixer and allow your computer audio to be routed through the XS even sampled at the sampler input.

If you set it to 5&6 it will go to th3 Assign L&R Output jacks.

Thanks for the rundown -- for anyone reading, I found these options under WDM 'Audio Routing' in the YSFW Driver control panel, under Output -> Ports.

Simply by setting Ports under Output to 'FW L/R', I was able to construct the 'purposeful loopback' I described at the end of my last post. I can even apply effects processing to my system audio -- neat!

I do find the use of the term 'Return' confusing, considering that in this case the audio is originating entirely from the computer. I have to wonder if it's idiosyncratic due to a focus on audio originating from the XS tone generator, or is my confusion reflective of a lack of comprehension regarding the signal flow? 'Where has it gone for it to return from?'

Thanks again. I'll come back and share if I'm able to learn how/why inputs monitored at the system level are showing up in the signal arriving from the XS (the oddity demonstrated in video above). For the record, at the time of recording that video, both the Input and the Output Ports were set to Main L/R in the WDM Routing settings.

Don’t let the fact that your audio interface is built-in the synthesizer fool you. Data coming into the Motif XS via FW as Audio interface are considered the audio RETURN... Particularly since you may send signal to the computer from the keyboard to trigger its audio, the Outputs of the computer audio device is returned to the XS (as interface) for direction or redirection to either speakers or elsewhere.

The XS is 16-in/6-out Audio Interface. The XS, as Synth, Sends 16 Audio buses IN to the computer, and returns 6 Audio buses OUT from the computer.

The 16 XS’s audio Outs are INs to the computer, all 6 OUTs from the computer Return to the XS, as audio interface.

I thought I'd go ahead and share a "symptomology" update here; I haven't heard back from Yamaha support yet, but I do better understand how to describe exactly what is happening now.

It appears to be a bug specifically with the WDM feature of the YSFW Driver. When the bug manifests, audio is sent to what I will call "[CurrentPort + 1]". That is:

• If Main L&R is selected then the audio routes to FW L&R
• If FW L&R is selected, it routes to Asgn L&R.
• If Asgn L&R is selected, the audio seems to disappear (routed into oblivion)

To make sure I'm aware of when audio is headed to FW L&R I've adjusted the Chorus and Reverb Send on the mLAN audio to 127.

Elaborating more specifically on the example shown in the video above: when monitoring is activated on a separate (non-YSFW) audio input device in the Windows 10 audio settings, the monitored audio is routed to [CurrentPort + 1]. I found that I can even change my system output device to something other than the Motif and the monitored audio is still routed to YSFW [CurrentPort + 1]!

I encountered the same routing problem in another, perhaps stranger, place. When playing a monophonic sound file in a media player, the audio from the media player is routed to [CurrentPort + 1]. When playing a stereo file in the same player, the audio is properly routed.

Strangest of all (but as of yet non-reproducible), I encountered a situation where a YouTube video playing in a Chrome tab would route to [CurrentPort + 1] yet other YouTube videos in other tabs routed fine! This is likely related to the situation I first described regarding the voice call. The music (coming from a Chrome tab) must have been mistakenly routing to FW L&R and so when the voice call started with the wrong audio input selected (Motif rather than microphone interface) the music came right through.

I'll update when I hear something from Yamaha. In the meantime, hopefully this more thorough description can help anybody else dealing with routing-related confusion on Windows 10.

If Main L&R is selected then the audio routes to FW L&R
If FW L&R is selected, it routes to Asgn L&R.
If Asgn L&R is selected, the audio seems to disappear (routed into oblivion)

To make sure I'm aware of when audio is headed to FW L&R I've adjusted the Chorus and Reverb Send on the mLAN audio to 127.

Extremely strange... to be sure you understand the role of the XS when it is acting as your audio interface:

If you select “Main L&R” the audio of your computer will be routed directly to the jacks on the XS back panel labeled “Main L&R”

If you select “FW L&R” the audio of your computer will be routed to the internal XS mixer before being routed to the “Main L&R” Output (but it will still be routed to the “Main L&R” Outputs... that’s how it gets to your speakers... they are connected to the Main L&R Outputs. The difference is the former goes directly to the Outputs, the latter goes through the internal XS engine before routing to the speakers.

If you select “Asgn L&R” the audio of your computer does not “go to oblivion”, it should go to the jacks on the back panel labeled “Assignable L&R”... these can be used to feed a second pair of monitors, or to create a separate mix (for musician’s headphones, for example) or to feed a separate mix to a separate system. Pro software like Cubase Pro lets you create multiple mixes which can be routed independently.

It’s not oblivion, to hear the signal routed to “Asgn L&R” you would need to connect a pair of speakers to those Outputs. Unlike the first two options (which both ultimately arrive at the Main L&R), the Asgn L&R has its own discreet analog Output.

We want to make sure you have not just misinterpreted what each Output is about.

EXAMPLE
If you route the computer audio to “Main L&R” you will not be able to add effects or change the sound of the signal. It goes directly to the speakers.
If you route computer audio to “FW L&R”, it arrives as AUDIO IN in the XS, you will be able to adjust its volume, Pan position, add XS Reverb and Chorus to the signal, you can route it to the XS sampler before you route it to the “Main L&R” Output where it can be heard. Also recognize you could reroute back to the computer using the AUDIO IN parameters in the XS - the OUTPUT SELECT let’s you route the signal— you would do this when you want to record audio from one computer application (YouTube) to an individual audio track of a DAW software like Cubase.

When you select an audio Port in your computer setup, the audio is INITIALLY going to that port of the XS.

Your report on what happens to the audio when not using the YSFW Driver should be completely meaningless in this setup. When not using the YSFW driver no audio should be routed via the XS, period. If you are still getting computer audio through the XS at that point, that’s a whole different problem (computer issue)... I could be wrong but that’s how I read it, from the info provided thus far.

I don’t get what’s unusual in the video, because I guess I’m not clear what it is supposed to show, sorry.

Extremely strange... to be sure you understand the role of the XS when it is acting as your audio interface:

If you select “Main L&R” the audio of your computer will be routed directly to the jacks on the XS back panel labeled “Main L&R”

If you select “FW L&R” the audio of your computer will be routed to the internal XS mixer before being routed to the “Main L&R” Output (but it will still be routed to the “Main L&R” Outputs... that’s how it gets to your speakers... they are connected to the Main L&R Outputs. The difference is the former goes directly to the Outputs, the latter goes through the internal XS engine before routing to the speakers.

If you select “Asgn L&R” the audio of your computer does not “go to oblivion”, it should go to the jacks on the back panel labeled “Assignable L&R”... these can be used to feed a second pair of monitors, or to create a separate mix (for musician’s headphones, for example) or to feed a separate mix to a separate system. Pro software like Cubase Pro lets you create multiple mixes which can be routed independently.

It’s not oblivion, to hear the signal routed to “Asgn L&R” you would need to connect a pair of speakers to those Outputs. Unlike the first two options (which both ultimately arrive at the Main L&R), the Asgn L&R has its own discreet analog Output.

We want to make sure you have not just misinterpreted what each Output is about.

Thanks to your help this past week (in the interim since this thread was created), I do indeed understand how the routing and various settings function. I think you might have misunderstood or misread my post. I completely understand that it must read bizarrely, because it is a bizarre issue. If only you could have heard my shouts of astonishment as I ran into each separate example that I described above. The YouTube one happened literally as I was reviewing a just-uploaded video of myself demonstrating the mono/stereo example to be sent to Yamaha support. I'm not sure I've ever been quite so astonished by the misbehavior of a driver before!

I'm aware that the FW L&R setting sends system audio through the mixer. That's why I've made sure that the mixer noticeably alters the signal (Chorus and Reverb Send) prior to its arrival at the speakers: so that I can hear without any doubt when it is occuring.

Also, the dotted-list near the beginning is describing what happens specifically to misbehaving audio -- I'm not describing the natural operation of the Asgn L&R setting. I'm describing what that setting does to certain audio at certain times. At such a time, the FW L&R setting verifiably sends the audio to the discreet analog Assignable Output and the Main L&R setting sends audio to the XS mixer prior to speakers while the Asgn L&R setting leaves the audio nowhere to be found (not even at the Assignable Outputs, I checked there first).

I think that in this case sound and video are worth 1 kiloword, so here is the video I recorded for Yamaha support demonstrating my mono/stereo soundfile example:
https://youtu.be/YS4MhJ4GTG8

Once again the Chrome example of the routing bug popped up literally as I was reviewing that video in order to post here. So, I made another video:
https://youtu.be/KxrO3lpLmmI

I’m sure your videos make sense to you but show them to a friend of yours (pick one at random) see if they can follow the explanation of the issue by just watching the video. We trust you that you are getting a strange result - rather than trying to prove that, show you have it setup as your would when following the normal directions.

But missing from your video and post are the basics
1) State what you want to accomplish (as I read it you are trying to send audio of your XS over your gaming system) ? Am I right, that’s what you want to do, correct? I’ve lost track.
2) eliminate all other possible settings and devices (you have scores of screens and other programs open in the back, this lowers confidence of the viewer as to what your actually running at the same time) it makes it confusing. Since much of the negotiation that sets up a driver’s role are implemented during the launch of an application or during boot up, you may have found a change that quite frankly requires a reboot to straighten itself out. Again not being clear on your goal (and never having wanted to do this). Perhaps once you make your change, you might indeed need to restart either the program (application) or the computer, for the functional change to take place. (Just a guess).
3) if you open a drop down, in a video please take the time to explain what it is, the viewer sees you are selecting options but the viewer is NOT included in what the options are or why the one you selected is better than the others. We just have to follow you... and every time the issue occurs. Does the issue actually occur in the video?

Close everything but what you want to work with and that you want the viewer to focus on.... just for troubleshooting’s sake. If you’re attempting to prove Windows 10 can do some wacky stuff when you have lots of things go8ng... I’m not sure that needs proof, we will stipulate that. But by stating what it is you want to do, then setting up and making just the recommended settings... is all you should focus on in a troubleshooting video scenario.

Seeing what happens when you try such and such (like selecting a mic that uses the computer’s native driver, doesn’t mean much if it’s not something you need to do... what was the purpose of using the computer’s microphone, in all of this? Why not use a microphone connected to the XS?

Hopefully, you will hear from the support folks sounds like an issue with navigating Windows, but I can’t really say because I cannot duplicate your issue here. Frustrating to be sure... let us know when/if you finally solve it.

Just to check because I'm not clear, are you referencing the original video linked in the first post or the two new ones which much more clearly show the strange behavior? I agree that the original video is a mess, due in no small part to an incomplete understanding of the Motif's audio routing and YSFW at the time, so I've now deleted it to make sure that it doesn't cause anymore confusion.

Bad Mister wrote:

But missing from your video and post are the basics
1) State what you want to accomplish (as I read it you are trying to send audio of your XS over your gaming system) ? Am I right, that’s what you want to do, correct? I’ve lost track.

What I am trying to accomplish is the reliable use of the WDM feature in general. The Motif XS is my full-time audio interface. Whether I am watching videos on youtube, playing games, listening to music, or actually using the Motif's keyboard and/or tone-generator (with or without DAW) the XS audio interface is the only path from my only computer to my only speakers (well, the only speakers worth a damn).

The issue I have run into causes the WDM Audio Routing Port setting to not be respected. The audio goes the wrong way, unexpectedly sending audio through the XS mixer.

Regardless of what I am doing, it does not seem that WDM should ever send audio to FW L&R as long as Main L&R are selected. However, it sometimes does. I've managed to reproduce two times when the WDM Routing disrespects its own Port setting.

Lets ignore the first example due to its involving other sound drivers, and also the non-reproducible Chrome example for now (though it does interestingly show WDM routing two processes two ways at once, which would be a neat feature if it was controllable); focus only on the "mono/stereo" video for now. I believe this video meets your suggestions more than the others. WDM is sending stereo audiofiles to the correct Port, but sending monophonic audiofiles to the incorrect Port.

Adding a new and significant insight: monophonic audio is the common link between all three examples. My microphone is monophonic, and I have just realized that the video which was misbehaving in my Chrome demonstration also bears only a single channel of audio.

If I had the ability to re-title this thread, I'd go with this:

"YSFW - WDM - Windows 10 -- Monophonic Audio is Routed Incorrectly"

Edit: I see now that I do have this capability!

I’m sorry, I watched the video on mono/stereo and maybe I missed something but I see no mention of a microphone input. If I had a Windows 10 computer and XS I would attempt to duplicate your issue, I cannot, sorry. But even if I could you have completely confused me.

Is the microphone plugged into the XS?

You've conflated the three separate occurrences of the bug. It's as if I stubbed my toe at the bar, at the park, and at the church, and upon watching a video of the church incident you ask "Where's the bar stool that hurt your toe?"

Everything to do with the microphone was only to show another separate instance of the WDM driver improperly handling monophonic audio.

To better understand, forget about any microphone or alternate audio interface. Everything important is in the single video showing mono and stereo audio files headed to two different WDM Ports. Once you understand the demonstration that monophonic audio streams are being sent the wrong way by WDM, the other examples (microphone, Chrome browser) merely serve to illustrate that the bug is program-independent and not tied to the media player I'm using.

Everything to do with the microphone was only to show another separate instance of the WDM driver improperly handling monophonic audio.

It simply wasn't clear if the barstool was at the church or not...

Sorry, I simply did not understand your issue, (nor what it was you were trying to do). Sorry for my confusion. As I understand now when configuring WDM for your Windows applications a mono input causes problems.

I will report your findings - I am not sure where the issue exists or if it has something to do with Windows Driver Model and how it deal with MONO (which I do not know) or a conflict with the YSUSB Driver, or both or neither. I'll let you know.