The VideoLAN Forums

I transcode to a file as well as duplicate the display to the a window in my ui (via dshow). In my ui I have a volume slider. This volume slider sets the volume of the audio session via the wasapi. It is vlc that initializes this audio session when it starts the audio output stream. Everything works fine on windows 7. But when I get to windows 8, various flaky things happen whenever I access anything to do with the audio session (various wasapi calls). I believe the problem might be related to this:

I noticed the following message on Microsoft's online document page ( http://msdn.microsoft.com/en-us/library ... 85%29.aspx ):
---------------------
Note In Windows 8, the first use of IAudioClient to access the audio device should be on the STA thread. Calls from an MTA thread may result in undefined behavior.

I looked at the wasapi vlc code, and sure enough we are initialising the audio client on a mta apartment (D:\vlc_source\modules\audio_output\winstore.c):

static void EnterMTA(void)
{
HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
if (unlikely(FAILED(hr)))
abort();
}

To make this a STA apartment, we need to change the parameter from COINIT_MULTITHREADED to COINIT_APARTMENTTHREADED

I have the source checked out, but I don't have a windows build environment setup, nor am I a contributor.

I do not think that would work. Note the the in "the STA thread".

Thanks for the reply.

My understanding is that it would create an apartment with a single thread instead of multiple threads:


https://msdn.microsoft.com/en-us/library/ms809971.aspx

To create an STA, a thread simply calls CoInitialize or CoInitializeEx(NULL, COINIT_APARTMENTTHREADED), thereby associating the calling thread with the apartment until it calls CoUninitialize. Successive calls to either of these functions by the same thread do not create additional apartments or enable you to change the concurrency model of the apartment.

And I should mention, that I don't know that this is the root of the flakiness I am seeing. I am also getting a strange initialization delay on some windows 8 machines:

2015-07-09 08:07:41.0762 Implementation.NLogger.Debug Debug EnumDeviceCaps: output pin: Capture
2015-07-09 08:07:41.0762 Implementation.NLogger.Debug Debug EnumDeviceCaps: input pin: Master Volume
2015-07-09 08:07:41.0762 Implementation.NLogger.Debug Debug EnumDeviceCaps: trying pin Capture
2015-07-09 08:08:31.1853 Implementation.NLogger.Debug Debug EnumDeviceCaps: input pin default format configured

It's almost a minute between "trying pin Capture" and "input pin default format configured".

I'm not sure I totally understand your comment, but are you saying that it would need to be called on the main thread that instantiates the vlc instance (i.e. exposed as part of the libvlc api)?

I can't be more precise than Microsoft.

lol, depends what you think of micrososft's precision.

So are there issues around audio in windows 8? I'm certainly experiencing some. We moved our testing out of our code and into VLC player, we are seeing the audio sync/init delay from 2.1.3 onward. This is just on streaming to the display from a capture device, in our code we are duplicating the input to transcode to a file as well.

Likely this is not releated, but I noticed an audit error in Windows Logs every time I ran VLC. It said:

Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.

File Name: \Device\HarddiskVolume5\Windows\System32\dsound.dll