When I run this code:
MIXERLINE MixerLine;
memset( &MixerLine, 0, sizeof(MIXERLINE) );
MixerLine.cbStruct = sizeof(MIXERLINE);
MixerLine.dwComponentType = MIXERLINE_COMPONENTTYPE_SRC_WAVEOUT;
mmResult = mixerGetLineInfo( (HMIXEROBJ)m_dwMixerHandle, &MixerLine, MIXER_GETLINEINFOF_COMPONENTTYPE );
Under XP MixerLine.cChannels comes back as the number of channels that the sound card supports. Often 2, these days often many more.
Under Vista MixerLine.cChannels comes back as one.
I have been then getting a MIXERCONTROL_CONTROLTYPE_VOLUME control and setting the volume for each channel that is supported, and setting the volumne control to different levels on different channels so as to pan music back and forth between the speakers (left to right).
Obviously under Vista this approach isn't working since there is only one channel. I can set the volume and it is for both channels at the same time.
I tried to get a MIXERCONTROL_CONTROLTYPE_PAN for this device, but that was not a valid control.
So, the question for all you MMSystem experts is this: what type of control do I need to get to adjust the left/right balance? Alternately, is there a better way? I would like a solution that works with both XP and Vista.
Computer Details: Running Vista Ultimta 32 bit SP1 and all latest patches. Audio is provided by a Creative Audigy 2 ZS card with 4 speakers attached which can all be properly addressed (controlled) through Vista's sound panel. Driver is latest on Creative's site (SBAX_PCDRV_LB_2_18_0001). The Vista sound is not set to mono, and all channels are visable and controlable from the sound panel.
Running the program in "XP Compatibility Mode" does not change the behaviour of this problem.
If you run your application in "XP compatibility" mode, the mixer APIs should work much closer to the way they did in XP.
If you're not running in XP mode, then the mixer APIs reflect the mix format - if your PC's audio solution is configured for mono, then you'll see only one channel, but if you're machine is configured for multichannel output the mixer APIs should reflect that.
You can run the speaker tuning wizard to determine the # of channels configured for your audio solution.
Long time Microsoftie Larry Osterman has a blog where he discusses issues like this because he was on the team that redid all the audio stuff in Vista.
In the comments to this blog post he seems to indicate that application controlled balance is not something they see the need for:
CN, actually we're not aware of ANY situations in which it's appropriate for an application to control its balance. Having said that, we do support individual channel volumes for applications, but it is STRONGLY recommended that apps don't use it.
He also indicates that panning the sound from one side to the other can be done, but it is dependent on whether the hardware supports it:
Joku, we're exposing the volume controls that the audio solution implements. If it can do pan, we do pan (we actually expose separate sliders for the left and right channels).
So that explains why the MIXERCONTROL_CONTROLTYPE_PAN thing failed -- the audio hardware on your system does not support it.
Related
Link to the bug report on 'Feedback Hub'
An audio endpoint device, from here on referred to as 'endpoint', is a physical or virtual audio output or input device.
With the Windows 10 April Update 1803 the long overdue 'App volume and device preferences' have been introduced. These settings allow more control over audio stream management as it is now possible to set different endpoints for different applications, no matter whether that particular application comes with an endpoint selection or not.
However, there is an issue where the audio of a program, whose endpoint is non-default, is streamed through the default endpoint (or not at all) after it has been closed and launched again, although the endpoint is displayed correctly in the settings:
As far as I know the issue can be recreated on a Windows 10 machine (version 1803 or higher) with any virtual or physical endpoint and an affected program. I used 'VLC Media Player' in this example (disregarding the fact that it comes with an endpoint selection) as it is well known and widely accessible, which should make it easier to recreate the issue.
What I'm searching for...
... is a programmatically solution to switch between endpoints, which ideally can be launched in form of a script to set the correct endpoint with an application launch.
For my purpose it would be enough to have to adjust the device instance path manually, as the device would be always the same, but I'm not going to complain about a solution which retrieves the device instance path from the registry, too.
Defined endpoints and the device instance path of the device they are using can be retrieved from the subkeys of the key HKEY_USERS\# YOUR SID #\Software\Microsoft\Multimedia\Audio\DefaultEndpoint. I don't know how windows generates the name of the subkeys or where they can be found. If I had to take a wild guess, I'd say these are Application IDs (feel free to correct me if I'm wrong).
The device instance path itself can be found in the Device Manager (under 'Audio inputs and outputs' double click the desired device, navigate to the tab 'Details' and select 'Device instance path' from the 'Property' drop-down menu).
Additionally the entry about Audio Endpoint Devices and Stream Management in the Microsoft Docs might be helpful, but that is way above my head.
A possible but impractical workaround...
... would be, to manually set another endpoint for the application and switch back to desired endpoint at every launch of said application (as shown above).
But not just takes this at least 10 seconds at each and every launch, you might even forget to do this as the audio might just get streamed through the default endpoint *¹.
The alternative to the latter is, that no audio will be streamed at all *² or in some cases it actually works *³.
*¹ e.g.: VLC Media Player, Tom Clancy's Rainbow Six Siege (although the audio will be streamed correctly during the splash screens)
*² e.g.: Call of Duty 4: Modern Warfare, Call of Duty: Modern Warfare 2, Call of Duty: Modern Warfare 3
*³ e.g.: Window Media Player, Microsoft Edge, Firefox
Observations
VLC Media Player comes with an endpoint selection, but so does TeamSpeak 3 and, unlike VLC, it skips the Windows settings completely.
Call of Duty not streaming any audio most likely is connected to the engine as I didn't encounter any other application doing something similar.
Windows Media Player, Microsoft Edge and Firefox are the only programs (I tested so far) which work fine. They have no endpoint selection (I'd know of) and will use the correct endpoint after closing and launching it again. It should be noted, however, that Firefox and Microsoft Edge will show multiple instances in the "App volume and device preferences" when adjusting the endpoint.
Disclaimer
I already tried two 3rd party softwares: 'Audio Router', which didn't work at all and 'CheVolume', which doesn't solve the issue and constantly crashes while doing so.
This question is based on one I asked over at Super User (here), where I didn't get an answer I was able to work with due to my lack of knowledge regarding actual programming (I'm only somewhat familiar with Batch and PowerShell). I'm well aware that neither Stack Overflow nor Super User are script writing services, however, the issue is not being fixed with the Windows 10 October Update 1809 and I see this as a problem which is affecting not just me and with that would be helpful for multiple people after me. Feel free to write a comment or propose an edit if you see this differently.
I'm also not sure whether the tags 'audio-streaming' and 'endpoint' should be used in this context, please propose an edit if they shouldn't or you can think of any better.
Edit - 05/11/18
Using the 3rd party software 'EarTrumpet' I was able to overcome the issue with the 'Call of Duty' games (no audio at all after restarting), however, 'VLC Media Player' would not restart after I assigned a non-default endpoint with 'EarTrumpet' until I closed 'EarTrumpet' again and the issue with 'Tom Clancy's Rainbow Six Siege' remains the same.
Edit - 18/01/19
Added link to a bug report I created on the 'Feedback Hub' 2 month ago.
Edit - 20/01/19
After doing some testing again it should be noted that having 'EarTrumpet' run in the background will keep a non-default endpoint for 'VLC Media Player' across restarts, however, 'VLC Media Player' will only (reliably) restart when the non-default endpoint was set in the 'App volume and device preferences'.
I do not have any solution regarding a programming language to handle such events.
But I can recommend EarTrumpet app to handle this change more quickly https://www.theverge.com/2018/6/13/17457778/eartrumpet-windows-10-audio-app
(Windows store: https://www.microsoft.com/en-us/p/eartrumpet/9nblggh516xp?ranMID=24542&ranEAID=nOD%2FrLJHOac&ranSiteID=nOD_rLJHOac-hUn6PgKuMKwQLdrzRqnPTA&epi=nOD_rLJHOac-hUn6PgKuMKwQLdrzRqnPTA&irgwc=1&OCID=AID681541_aff_7593_1243925&tduid=%28ir__qwqlg6jd0jba3y9hpnbvikaite2xk6kuyv9udtr100%29%287593%29%281243925%29%28nOD_rLJHOac-hUn6PgKuMKwQLdrzRqnPTA%29%28%29&irclickid=_qwqlg6jd0jba3y9hpnbvikaite2xk6kuyv9udtr100&activetab=pivot:overviewtab )
I will update the answer if I find a easy way to script/program a change of output on each app.
I need to do some basic video processing from the Webcam in Windows Phone 8.1.
I cannot find any examples of how to access the webcam preview buffer. The Microsoft examples (very few) all have a video preview frame activate, I can find none that show how to subscribe to a 'new frame ready' event, or where the buffer is.
The MediaCapture, and CaptureDevice appear to be the main ways of reaching the camera in this api.
Can anyone point to a specific example? For instance, a QR code reader, or maybe a program that adds video effects, like greyscale, would need to attach an event to every frame.
Thanks.
It sounds like you need to access the buffer from the preview stream of the phone cameras. If you absolutely need to target 8 and 8.1, then you should look into GetPreviewBufferArgb(out int[] pixels). See here: https://msdn.microsoft.com/en-us/library/windows.phone.media.capture.cameracaptureframe.getpreviewbufferargb.aspx
But if you can instead target Windows 10, you get the benefit of fully universal APIs, and you don't take a dependency on the likely soon to be deprecated (if not already) Windows.Phone.Media.Capture namespace. I would strongly recommend doing this instead, as the APIs will be easier to work with, and any 8.1 device can upgrade to 10 for free.
Here is a fully working Windows 10 sample: http://aka.ms/2015buildgetpreviewframesample, which was shown off at the last Build conference (video here: http://channel9.msdn.com/Events/Build/2015/2-730).
I have created 16 Direct3D devices with size approximately 320x200 pixels. I invoke IDirect3DDevice9::Present for each device in a separate thread every 40 ms. On laptops with Windows XP and integrated Intel GMA945 graphics part of devices is not updated if system tooltip or Start menu are shown. IDirect3DDevice9::Present doesn't return any error codes at that moment, in program everything looks fine, but user can see that move on several of devices freezes. What could be a reason for that?
This works fine on Windows 7 with the same hardware and on Windows XP with different hardware, so the problem only with this combination. I should support this since my customers are use this combination of the hardware and OS. MSDN says nothing about that I should create only one D3D device (at least I can't find it) so problem should be elsewhere.
What I'm trying to find is that possibly there's some combination of flags that could solve my problem. At the moment I use the following:
D3DPRESENT_PARAMETERS param = {};
param.Windowed = TRUE;
param.SwapEffect = D3DSWAPEFFECT_DISCARD;
param.hDeviceWindow = GetSafeHwnd();
param.BackBufferCount = 1;
param.BackBufferFormat = D3DFMT_UNKNOWN;
param.BackBufferWidth = m_szDevice.Width;
param.BackBufferHeight = m_szDevice.Height;
param.MultiSampleType = D3DMULTISAMPLE_NONMASKABLE;
param.Flags = D3DPRESENTFLAG_VIDEO;
param.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;
param.MultiSampleType = D3DMULTISAMPLE_NONE;
param.MultiSampleQuality = 0;
Don't do that. The device is supposed to map basically 1-to-1 to a GPU. Create one device, and use it to draw to 16 different windows, in whichever way works for you. (Multiple swap chains is the usual approach, afaik)
Creating 16 devices and trying to get them to render in parallel is just asking for trouble.
D3D is designed around the assumption that only one device will be doing serious rendering at any time.
In theory, the difference should only be a matter of performance, but in your case, trying to run 16 devices in parallel on a crappy Intel GPU, it wouldn't surprise me if it causes rendering errors such as you'er seeing.
I've distributed DirectX software for a couple of years and along the way learnt that Intel graphics chipsets have incredibly crap drivers. Once I even saw a driver revision that couldn't render a quad properly. So when you have a problem with an Intel chipset, if you're on the latest driver version, you pretty much have to accept your solution is going to be "start shotgun hacking things until it works".
Sorry to give you a lame answer, but Intel chipsets are not well engineered at all. They're solely there to get something - anything - on the screen, probably for office worker type use. Beyond "does it do aero glass" Intel probably don't give a hoot what it does or how well it works. An alternative "solution" is to distribute your application anyway, state that Intel chipsets are not supported due to glitches in the hardware/driver support, and contact Intel and see if you can get a fix from them.
And people say OpenGL has bad drivers...
First of all, when you say "doesn't return any error codes at that moment", are you running the D3D9 debug version at max debugging level?
Second, everytime you create a new device and it gains focus, the surfaces of all the existing devices are lost. Are you calling reset on all of them after creation?
Other than that, it's like the other answers state: don't create many devices from a single application. Device creation might start throwing errors after 9 or 10 devices, you are really pushing it with 16. Use a single device with multiple swap chains in stead, see for instance this DirectX 8 tutorial.
Intel graphics chips, particularly the integrated GMA ones, have never been known for their capabilities. They can report caps they don't have and later fail, with or without errors codes (had bug reports of this, supposedly supported shader models later failed to compile). It is possible that you're running into a similar problem with their chips/drivers. Does it work on other hardware or with different drivers?
I assume, from having multiple devices, they are windowed? Have you checked the window handles, or tried explicitly passing the handle/viewport when presenting? Do any of the devices get reset?
It is possible the display drivers are not properly repainting the window after the tooltip or start menu are shown (more likely if its a window under the tooltip/menu). Have you checked the window for focus, made sure it gets painted, etc?
I am trying to fix an Audacity bug that revolves around portmixer. The output/input level is settable using the mac version of portmixer, but not always in windows. I am debugging portmixer's window code to try to make it work there.
Using IAudioEndpointVolume::SetMasterVolumeLevelScalar to set the master volume works fine for onboard sound, but using pro external USB or firewire interfaces like the RME Fireface 400, the output volume won't change, although it is reflected in Window's sound control panel for that device, and also in the system mixer.
Also, outside of our program, changing the master slider for the system mixer (in the taskbar) there is no effect - the soundcard outputs the same (full) level regardless of the level the system says it is at. The only way to change the output level is using the custom app that the hardware developers give with the card.
The IAudioEndpointVolume::QueryHardwareSupport function gives back ENDPOINT_HARDWARE_SUPPORT_VOLUME so it should be able to do this.
This behavior exists for both input and output on many devices.
Is this possibly a Window's bug?
It is possible to workaround this by emulating (scaling) the output, but this is not preferred as it is not functionally identical - better to let the audio interface do the scaling (esp. for input if it involves a preamp).
The cards you talk about -like the RME- ones simply do not support setting the master or any other level through software, and there is not much you can do about it. This is not a Windows bug. One could argue that giving back ENDPOINT_HARDWARE_SUPPORT_VOLUME is a bug though, but that likely originates from the driver level, not Windows itself.
The only solution I found so far is hooking up a debugger (or adding a dll hook) to the vendor supplied software and looking at the DeviceIOControl calls it makes (those are the ones used to talk to the hardware) while setting the volume in the vendor software. Pretty hard to do this for every single card, but probably worth doing for a couple of pro cards. Especially for Audacity, for open source audio software it's actually not that bad so I can imagine some people being really happy if the volume on their card could be set by it. (at the time we were exclusively using an RME Multiface I spent quite some time in figuring out the DeviceIOControl calls, but in the end it was definitely worth it as I could set the volume in dB for any point in the matrix)
Very simple question. In the MSDN documentation for the DirectSound API they state that when my application is in focus it will be the only audible program. This is exactly what I want to happen, however when setting this flag and playing sound through my application, I can still hear the background music on my computer.
So the question is, why? Is it because the application playing the background music using a different low level API, and thus different mixing buffers? Or is there some other little trick i need to tweak in order to become the only audible application.
I asked a similar/related question here, with no response. But once again if you don't know the answer to the specific DirectSound question, but you know a way of becoming the only audible application with a different API let me know!
Thanks, I'm on Windows XP 32Bit Professional, if it makes a difference.
A long time ago, the Windows developers realized that allowing one application to have total control of the audio system (whereby muting other apps) was a bad idea. And then they subsequently deprecated many of these "exclusive" and foreground/background mode flags. I believe this behavior change goes all the way back to DirectX 7.1 (WinME) and then formally everywhere on DX 8. This was 10 years ago.
Imagine your video conferencing app becoming muted when you switched the foreground application to an app that ran audio in some sort of exclusive mode. Not being able to reliably hear anyone when switching between apps is not a great experience.
As a matter of fact, prior to DX 8, many popular voice-comm apps for multi-player gaming would continually sniff for the foreground window handle and use that for the call to SetCooperativeLevel such that they wouldn't get muted.
I think it would be interesting to know, "what is that you really want to do?" that makes you assume you need total control of the audio output.
On Vista and higher, there is the WASAPI api for low-level audio. I believe there is a concept of "exclusive" mode but I don't know if trumps other apps using the sound card. YMMV.