Re: wined3d: Use backup swapchain DC for devices created with desktop window. (try 2)
Hello Is there a status update on this patch? I am curious to know if it will be merged, and if not, what correction is needed to make it mergeable. Thanks Jeff On Mon, Sep 3, 2012 at 1:51 PM, Adam Jakubek wrote: > On Mon, Sep 3, 2012 at 6:29 PM, Stefan Dösinger > wrote: >> >> I skimmed bug #18490, and I'm wondering about two things: Does the app >> create >> a D3DDEVTYPE_REF or D3DDEVTYPE_NULLREF device? Once the device is created, >> what does it to with it? A +d3d log would provide some answers. > > > Ok, this needs a little correction on my part. The game actually creates > D3DEVTYPE_HAL (I somehow previously concluded it wouldn't work, since on my > test machine it required software vertex processing). > Here is the relevant log line: > trace:d3d:wined3d_device_create wined3d 0x235ce558, adapter_idx 0, > device_type 0x1, focus_window 0x20026, flags 0x22, device_parent 0x2284cc0c, > device 0x2284cc14. > > Focus window is the desktop handle. Presentation parameters specify windowed > mode and hDeviceWindow=NULL, so in the end it uses the desktop window. > > It seems to be some kind of short-lived auxiliary device for texture > operations. It's not used for rendering at all. > The only operations on that device I could find is a series of CreateTexture > calls: > trace:d3d9:d3d9_device_CreateTexture iface 0x2284cc08, width 2048, height > 2048, levels 1, usage 0, format 0x15, pool 0x2, texture 0x33be40, > shared_handle (nil). > > They are followed by several LockRect/UnlockRect calls, after which the > textures are released. > The device is released immediately after that. > > Originally I suspected this might be used to generate mip-maps or load > textures with d3dx, but the presence of D3DPOOL_SYSTEMMEM excludes both. > > I admit that it's a very non-standard way of creating a D3D device, since it > can't render anything. However it seems to work for this particular use > case. > > Regards, > Adam Jakubek > > > >
Re: Status on SetPixelFormat patch from May 2010
On Fri, Dec 30, 2011 at 11:43 PM, Henri Verbeet wrote: > On 30 December 2011 22:15, Chris Robinson wrote: >> years ago. I think a better fix would be for wined3d to use a dummy surface, >> or a renderless context (available with OpenGL 3.0), if it's asked to use the >> desktop window. >> > Yes, we do something along those lines in ddraw, and we'll likely move > it to wined3d after 1.4. > Do you mind going into more detail on the motive for waiting for 1.4? I was under the impression that WINE didn't usually postpone big changes until an rc series was ongoing or at least anticipated. Is there discussion of starting the 1.4 RC phase soon, and that's the motive for holding off? I am just curious to know why you're waiting.
Status on SetPixelFormat patch from May 2010
Hello all I am curious about the patch on http://bugs.winehq.org/show_bug.cgi?id=18490 and why it's not in vanilla. http://bugs.winehq.org/show_bug.cgi?id=18490#c9 seems to be a pretty cogent explanation of the issue and the patch appears reasonable enough. It prevents a major crasher in Empire: Total War, which otherwise works really well. Maybe it was just never submitted to wine-patches? Thanks Jeff
LLVM compilation
Just wondering if anyone has experimented building WINE with LLVM instead of GCC. For those who haven't been following it closely, LLVM/Clang is fairly mature now and can now build some really mammoth projects. Has anyone experimented in building WINE with LLVM/Clang? If so, what results were gotten? My understanding is that WINE tries hard to be pretty portable and non-GCC-specific, so I would expect good results... Thanks From Jeff
Re: [PATCH] winealsa.drv: Count micelem in mixer chans, don't add spare capture input for half-duplex mics.
On Wed, Sep 1, 2010 at 9:40 AM, Alexandre Julliard wrote: > This statement wasn't exactly clear before, but now it's really > impossible to follow. Please rewrite this in a way that makes sense to a > casual reader. I have rewritten this in a more readable way and submitted the result to wine-patches. See http://source.winehq.org/patches/data/67063 . -Jeff
Re: DIB clarification
On Sun, Aug 29, 2010 at 7:12 PM, Jeremy White wrote: >> This could also help. If I recall correctly, Jeremy White mentioned >> at Wineconf 2008 that this was a major reason they haven't invested >> serious energy into one themselves: they had a hard time finding an >> application that they cared about that benefited significantly from a >> DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't >> care about AutoCAD, or whether they hadn't tested with it, or whether >> my memory is just faulty, I'm not sure. > > Yes, that's essentially right, although note that we did invest some > fairly serious energy into the DIB engine prior to coming to that conclusion. > (I remember how pleased Huw was that his benchmarks were 1000 times > faster, and how displeased he was when it made Powerpoint slower...) > > That effort all went into Wine, and I hope and believe that it has > helped others as they have worked on the DIB engine. > > But we don't have any secret stash of DIB engine code to further our > evil plans for world domination. We rely on our gorgeous femme bots > and Alexandre's magic 'all' patch for that . > > Cheers, > > Jeremy > To clarify, it's not about having secret DIB engine code, it's about saying "I guess we just won't find time to provide useful feedback until some company sponsors it...", as I saw several times during the old threads. From Jeff
DIB clarification
I hate to stir the pot, especially as an unknown in the community, but I've spent the last few hours reading WINE's history regarding DIB engines and it is pretty distressing. I have seen expressions of frustration from many regarding the handling of the mostly-functional DIB engine that Massimo wrote. AJ's terseness on the issue is puzzling. I find it really weird that such a major and long-standing thing would just be left to languish without any detailed reasons. Though I do not believe it, you can start to see why the slashdotter described Codeweavers' corporate agenda as "evil"; it almost feels like Codeweavers is holding DIB hostage, just waiting for someone to get fed up and fork over the cash for it. This wouldn't be a problem of course if it appeared that Alexandre was willing to work with external developers on the DIB engine, but he has given very sparse criticism. Should we all just accept that Massimo's engine is yet another DIB engine gone to waste and there is no future hope for it at all? Max's statements to that effect can be confusing out of context because of his non-native English, but everything I have seen indicates that he is totally willing to work on upstream merging if Alexandre is willing to cooperate. All cases of saying "it won't get merged" etc. by Max seem to reference AJ's reluctance to provide useful criticism on the code that gets posted. It is not my intention to start another huge flamewar or thread on the matter. I just want to promote a reliable roadmap and help resolve this -- it seems like a total shame that there have been multiple DIB engines written and no parts of any of them were deemed worthy of inclusion in WINE. Max at least has indicated a desire to modify the code as necessary if a useful road map or ideation were provided, so why is it so hard to get the road map? Alexandre is right that the architecture is a lot of work, but I am not asking for him to write out a complete spec, and I don't think the community is, either; the main thing, as far as I can tell, is that the interaction and feedback on a major step forward for WINE has been minimal. People are still reporting major speedups on bug #421 so I don't think this is a lost cause unworthy of effort as some suggest. The most feedback I was able to find from Alexandre was on May 2009's DIB engine passing all tests thread at http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 . Alexandre's single major standing complaints seem to be a lack of test cases and Massimo not establishing a good record with simple patches. Are those still valid reasons? The complaint regarding driver loading was addressed, but it sounds like Alexandre wants it in the opposite direction (forwarding calls from winex11.drv (or whatever driver) to winedib.drv instead of the other way around). Is that a very serious problem? So, if we can, let's get a few points down on what needs to be modified for DIB to make it into WINE, even as an experimental branch: 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Reverse the DIB ordering and call winedib.drv only as needed, instead of passing everything through winedib.drv first. 3) ? Or, in the case that Max's DIB is gone forever and is considered irreparable, why don't we discuss what's needed for a different DIB engine? 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Works well with any wine display driver. (already in Max's code) 3) Applied and developed cooperatively and incrementally with the WINE community 4) Easily disabled / non-disruptive (already in Max's code) 5) ? What else needs to go here? Is this accurate? Others mentioned that benchmarks that prove the usefulness of a DIB engine might help. Do those still need to be performed? Thanks for reading. From Jeff
Re: [PATCH 4/6] winealsa.drv: Append hw address to handle to prevent name collision. (resend)
On Tue, Aug 3, 2010 at 7:49 AM, Vitaliy Margolen wrote: >> + memcpy(ww->ds_desc.szDesc, description, >> + min( (sizeof(ww->ds_desc.szDesc) - 1), strlen(description)) >> ); > > This does not guarantee that ww->ds_desc.szDesc will be \0 terminated. > > Vitaliy. > What do you want me to do? This looks pretty safe to me and I just copied the block from elsewhere and replaced the variables. Do you want me to manually read to the end of ww->ds_desc.szDesc and replace with a \0? Sorry for the noobness. From Jeff
Re: [PATCH 5/6] winealsa.drv: Don't open the same card on every loop. (resend)
On Tue, Aug 3, 2010 at 3:57 AM, Alexandre Julliard wrote: > Jeff Cook writes: > >> @@ -753,7 +753,7 @@ static int ALSA_ScanDevices(int directhw, >> char *pcmname = NULL; >> snd_pcm_t *pcm; >> >> - sprintf(defaultpcmname, "default"); >> + sprintf(defaultpcmname, "default:%d", card); > > We used to do that, but it was changed because it's not correct, cf. bug > 10942. The thing here is that default:x seems to be the only way to get a card to open compatibly with most setups. I tried opening with plughw:x, hw:x, dmix:x, and any other prefix that was suggested, but default:x was the only thing that worked with my dmix-based ALSA setup. Since dmix is on by default in ALSA, I'd venture that most normal sound setups would break otherwise too. dmix:x worked with dmix, but still behaved oddly (I don't remember exactly what it did), and I reckon that it probably wouldn't work with setups that don't use dmix. Does anyone have a suggested device-opener that is both correct according to API/docs and correct in that it actually works with at least dmix? From Jeff > > -- > Alexandre Julliard > julli...@winehq.org >
Re: Help with 6120d7cc145, causing bugs
Wylda reported success with the attached patch on bug 23902. Does it seem OK to everyone else? In this case, the extra channel needed for capture is not added when a micelem is found, because micelem should only be found when there is no other suitable playback or capture controls (i.e. "Mic" element only). Though I'm not sure if that's working, so the micelem detection could probably still stand for some reworking, but this seems to fix things for now. On Fri, Aug 27, 2010 at 7:51 AM, Henri Verbeet wrote: > On 27 August 2010 15:14, wrote: >> All apps are working perfectly! Could i kindly ask you for sending >> to patches today? It looks like i will have spare time for testing, >> so it will help me to not to mess with revering. >> > It's probably not quite correct. In particular, before 6120d7cc145 > it's likely the Mic element would be counted in capcontrols as well, > and skipped for the chan count in some cases. Also, the channel count > for USB mics will probably end up as 2 now, which would make it hit > the "No channels found, skipping device!\n" path again. I think I'd > prefer the original author or Maarten to have a look at this, the code > looks somewhat complicated to me, perhaps more so than really needed. > micelem_chans.diff Description: Binary data
Re: [PATCH 1/6] winealsa.drv: Init mixer on cards with a single Mic control, like snd_usb_audio mics (try 2)
On Tue, Aug 17, 2010 at 3:00 AM, sudemon wrote: > On 03.08.2010 04:36, Jeff Cook wrote: >> >> What compiler are you running? It works fine for me and I don't see >> any errors or warnings. > > I also don't see any errors or warnings. > > Аfter 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 commit - my games just crash > on start without errors (windows version is win98). Found by Regression test > (16 august master VS wine-1.3.0). > > After this commands games don't crash: > $ git bisect reset > $ git show 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 | patch -p1 -R Sudemon, check out bug 23902. http://bugs.winehq.org/show_bug.cgi?id=23902 Try compiling from latest git, one of the fixes in that thread has already been committed. If that doesn't work, please try the patch located here: http://bugs2.winehq.org/attachment.cgi?id=30459 . From Jeff
Help with 6120d7cc145, causing bugs
Just wondering if I could get a bit more review on commit 6120d7cc145 which was committed in early August. Here's a link: http://source.winehq.org/git/wine.git/?a=commit;h=6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 There have been a few bug reports filed against it recently, see http://bugs.winehq.org/show_bug.cgi?id=23902 and http://bugs.winehq.org/show_bug.cgi?id=24131 . It seems that in some relatively rare sound setups, an inappropriate sound element gets fed in to filllines_no_master which leads to a crash on audio initialize. To me this is weird because the program is currently written so that it flows into filllines_no_master only if there no is master control. A patch adding else if (micelem) instead of just else was recently committed and fixed at least one person's problem. Some people on the bug report are unable to provide full debug information so it makes this harder. If you have the time, please review the patch and let me know what errors you notice that may be causing the aforementioned bug. I am new to Wine dev so please forgive anything really stupid. :) Thanks From Jeff. -- Jeff Cook (801) 231-3157 j...@deserettechnology.com
Re: Inviting Mono and pulseaudio to wineconf?
On Wed, Aug 25, 2010 at 12:10 AM, Roderick Colenbrander wrote: > I'm not against inviting Pulseaudio guys. Sure, Pulseaudio was added > to distributions way too early and there still are a lot of issues but > sound servers like pulseaudio are really the way to go for the future. > People want to be able to plug in lets say a usb headset (so another > soundcard) when playing a game and expect audio to move over to it or > want to see audio move over to their HDTV when they plug it in and > that's stuff which requires some form of arbiter at the user side. > > Having a good pulseaudio driver (in the new wine audio design) might > not be a bad thing. My understanding is that the new mmdevapi code leverages OpenAL, which theoretically should take care of the pulseaudio issues assuming both sides implement the protocol appropriately. > > Roderick
Re: [PATCH 1/6] winealsa.drv: Init mixer on cards with a single Mic control, like snd_usb_audio mics (try 2)
What compiler are you running? It works fine for me and I don't see
any errors or warnings.
On Mon, Aug 2, 2010 at 6:05 AM, Alexandre Julliard wrote:
> Jeff Cook writes:
>
>> @@ -245,6 +245,10 @@ static void fillcontrols(mixer *mmixer)
>> for (id = 0; id < mmixer->chans; ++id)
>> {
>> line *mline = &mmixer->lines[id];
>> + if (!mline->elem)
>> + {
>> + break;
>> + }
>> int ofs = CONTROLSPERLINE * id;
>
> You can't do that:
>
> mixer.c: In function ‘fillcontrols’:
> mixer.c:252: error: ISO C90 forbids mixed declarations and code
>
> --
> Alexandre Julliard
> julli...@winehq.org
>
[PATCH] winealsa.drv: Always scan devices, even if a default device exists.
Let me know what you guys think of this one, I think it will be
somewhat controversial. There is a registry key to enable this
currently, but it should really occur by default and maybe be
unchangeable. If you have multiple cards, like a USB mic for capture,
scan_devices to 0, as would occur on many configurations currently, is
undesirable and most users won't be able to work around it.
I'm not sure why scan_devices would be 0, maybe to prevent bugs while
probing or something, but I don't see much reason to disable scanning
all reported audio devices. Thoughts? Please let me know if I'm
missing anything.
From
Jeff
---
dlls/winealsa.drv/waveinit.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/dlls/winealsa.drv/waveinit.c b/dlls/winealsa.drv/waveinit.c
index 4ae93bb..0daa203 100644
--- a/dlls/winealsa.drv/waveinit.c
+++ b/dlls/winealsa.drv/waveinit.c
@@ -699,7 +699,11 @@ static int ALSA_ScanDevices(int directhw,
int fixedctlcard, int fixedpcmcard, int fixedpcmdev)
{
int card = fixedpcmcard;
-int scan_devices = (fixedpcmdev == -1);
+/* we always want to scan_devices; otherwise, if a default is set and the
+appropriate registry keys are not set, only the default device will be seen
+by wine. This is undesirable, for instance, if you have separate cards for
+capture and playback, like a USB microphone for capture */
+int scan_devices = 1;
/*
** Loop through all available cards
If we can't open a device as stereo, try mono. This is necessary for snd-usb-audio mics.
---
dlls/winealsa.drv/waveinit.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/dlls/winealsa.drv/waveinit.c b/dlls/winealsa.drv/waveinit.c
index 4da53c9..4ae93bb 100644
--- a/dlls/winealsa.drv/waveinit.c
+++ b/dlls/winealsa.drv/waveinit.c
@@ -106,6 +106,10 @@ static int ALSA_TestDeviceForWine(int card, int device, snd_pcm_stream_t stream
retcode = snd_pcm_hw_params_set_channels(pcm, hwparams, 2);
if (retcode < 0)
{
+retcode = snd_pcm_hw_params_set_channels(pcm, hwparams, 1); /* If we can't open stereo, try mono; this is vital for snd_usb_audio microphones */
+}
+if (retcode < 0)
+{
reason = "Could not set channels";
goto exit;
}
Init mixer on cards with a single Mic control, like snd_usb_audio mics
This patch fixes bug #12706 and creates a mixer for snd-usb-audio cards,
which have only a single Mic control and nothing else. Subsequent
patches may be needed to make this useful depending on configuration.
I am including this here for commentary before I submit to wine-patches.
This is my first patchset to WINE, so please forgive and correct me if I
am "doing it wrong".
Thanks
Jeff
---
dlls/winealsa.drv/mixer.c | 58
++---
1 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/dlls/winealsa.drv/mixer.c b/dlls/winealsa.drv/mixer.c
index cfdf95f..6ab6840 100644
--- a/dlls/winealsa.drv/mixer.c
+++ b/dlls/winealsa.drv/mixer.c
@@ -245,6 +245,10 @@ static void fillcontrols(mixer *mmixer)
for (id = 0; id < mmixer->chans; ++id)
{
line *mline = &mmixer->lines[id];
+if (!mline->elem)
+{
+break;
+}
int ofs = CONTROLSPERLINE * id;
int x;
long min, max;
@@ -332,17 +336,21 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
snd_mixer_elem_t *elem;
line *mline = mmixer->lines;
-/* Master control */
-MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(mastelem), -1, mline->name, sizeof(mline->name)/sizeof(WCHAR));
-mline->component = getcomponenttype(snd_mixer_selem_get_name(mastelem));
-mline->dst = 0;
-mline->capt = 0;
-mline->elem = mastelem;
-mline->chans = chans(mmixer, mastelem, 0);
-
-snd_mixer_elem_set_callback(mastelem, &elem_callback);
-snd_mixer_elem_set_callback_private(mastelem, mmixer);
-
+if (mastelem) {
+/* Master control */
+MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(mastelem), -1, mline->name, sizeof(mline->name)/sizeof(WCHAR));
+mline->component = getcomponenttype(snd_mixer_selem_get_name(mastelem));
+mline->dst = 0;
+mline->capt = 0;
+mline->elem = mastelem;
+mline->chans = chans(mmixer, mastelem, 0);
+
+snd_mixer_elem_set_callback(mastelem, &elem_callback);
+snd_mixer_elem_set_callback_private(mastelem, mmixer);
+} else {
+MultiByteToWideChar(CP_UNIXCP, 0, "Empty Master Element", -1, mline->name, sizeof(mline->name)/sizeof(WCHAR));
+}
+
/* Capture control
* Note: since mmixer->dests = 1, it means only playback control is visible
* This makes sense, because if there are no capture sources capture control
@@ -395,6 +403,22 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
}
}
+static void filllines_no_master(mixer *mmixer, snd_mixer_elem_t *captelem, int capt)
+{
+snd_mixer_elem_t *elem;
+line *mline = mmixer->lines;
+
+MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(captelem), -1, mline->name, sizeof(mline->name)/sizeof(WCHAR));
+mline->component = getcomponenttype(snd_mixer_selem_get_name(captelem));
+mline->dst = 0;
+mline->capt = 1;
+mline->elem = captelem;
+mline->chans = chans(mmixer, captelem, 1);
+
+snd_mixer_elem_set_callback(captelem, &elem_callback);
+snd_mixer_elem_set_callback_private(captelem, mmixer);
+}
+
/* Windows api wants to have a 'master' device to which all slaves are attached
* There are 2 ones in this code:
* - 'Master', fall back to 'Headphone' if unavailable, and if that's not available 'PCM'
@@ -414,7 +438,7 @@ static void ALSA_MixerInit(void)
char cardind[6], cardname[10];
snd_ctl_t *ctl;
-snd_mixer_elem_t *elem, *mastelem = NULL, *headelem = NULL, *captelem = NULL, *pcmelem = NULL;
+snd_mixer_elem_t *elem, *mastelem = NULL, *headelem = NULL, *captelem = NULL, *pcmelem = NULL, *micelem = NULL;
memset(info, 0, snd_ctl_card_info_sizeof());
memset(&mixdev[mixnum], 0, sizeof(*mixdev));
@@ -470,6 +494,9 @@ static void ALSA_MixerInit(void)
mastelem = elem;
else if (!strcasecmp(snd_mixer_selem_get_name(elem), "Capture") && !captelem)
captelem = elem;
+else if (!strcasecmp(snd_mixer_selem_get_name(elem), "Mic") && !micelem && !mastelem)
+// this is what snd-usb-audio mics look like; just a Mic control and that's it.
+micelem = elem;
else if (!blacklisted(elem))
{
DWORD comp = getcomponenttype(snd_mixer_selem_get_name(elem));
@@ -519,7 +546,7 @@ static void ALSA_MixerInit(void)
mastelem = pcmelem;
capcontrols -= !!snd_mixer_selem_has_capture_switch(mastelem);
}
-else if (!mastelem)
+else if (!mastelem && !captelem && !micelem)
{
/* If there is nothing sensible that can act as 'Master' control, something is wrong */
FIXME("No master control found on %s, disabling mixer\n", snd_ctl_card_info_get_name(info));
@@ -549,7 +576,10 @@ static void ALSA_MixerIn
Fwd: Possible patch for #12706
This is a patch that makes WINE detect snd_usb_audio mics and assign
them a mixer and working master control. See bug #12706 for more
information about this problem: http://bugs.winehq.org/show_bug.cgi?id=12706
I wasn't able to test it completely because I wasn't able to switch my
default input device to the USB mic and no one in IRC is helping with
this, but it might make things work because theoretically the only
problem was that WINE was ignoring devices that looked like
snd_usb_audio's microphones. I suggest that someone who CAN get
snd_usb_audio mic as their default test it out and confirm, I would
really appreciate that.
Thanks to all in IRC who helped me get things this far, especially
mlankhorst.
This patch is based against the current git HEAD, eaa227c12d8bb. I've
also posted it at the aforementioned bug.
--
Jeff Cook
(801) 231-3157
j...@deserettechnology.com
diff --git a/dlls/winealsa.drv/mixer.c b/dlls/winealsa.drv/mixer.c
index cfdf95f..352bc83 100644
--- a/dlls/winealsa.drv/mixer.c
+++ b/dlls/winealsa.drv/mixer.c
@@ -245,6 +245,10 @@ static void fillcontrols(mixer *mmixer)
for (id = 0; id < mmixer->chans; ++id)
{
line *mline = &mmixer->lines[id];
+if (!mline->elem)
+{
+break;
+}
int ofs = CONTROLSPERLINE * id;
int x;
long min, max;
@@ -258,6 +262,7 @@ static void fillcontrols(mixer *mmixer)
else
snd_mixer_selem_get_playback_volume_range(mline->elem, &min, &max);
+
/* (!snd_mixer_selem_has_playback_volume(elem) || snd_mixer_selem_has_capture_volume(elem)) */
/* Volume, always enabled by definition of blacklisted channels */
mmixer->controls[ofs].enabled = 1;
@@ -332,17 +337,23 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
snd_mixer_elem_t *elem;
line *mline = mmixer->lines;
-/* Master control */
-MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(mastelem), -1, mline->name, sizeof(mline->name)/sizeof(WCHAR));
-mline->component = getcomponenttype(snd_mixer_selem_get_name(mastelem));
-mline->dst = 0;
-mline->capt = 0;
-mline->elem = mastelem;
-mline->chans = chans(mmixer, mastelem, 0);
-
-snd_mixer_elem_set_callback(mastelem, &elem_callback);
-snd_mixer_elem_set_callback_private(mastelem, mmixer);
-
+if (mastelem) {
+FIXME("mastelem found on %s, building master...\n");
+/* Master control */
+MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(mastelem), -1, mline->name, sizeof(mline->name)/sizeof(WCHAR));
+mline->component = getcomponenttype(snd_mixer_selem_get_name(mastelem));
+mline->dst = 0;
+mline->capt = 0;
+mline->elem = mastelem;
+mline->chans = chans(mmixer, mastelem, 0);
+
+snd_mixer_elem_set_callback(mastelem, &elem_callback);
+snd_mixer_elem_set_callback_private(mastelem, mmixer);
+} else {
+FIXME("no mastelem, skipping\n");
+MultiByteToWideChar(CP_UNIXCP, 0, "Empty Master Element", -1, mline->name, sizeof(mline->name)/sizeof(WCHAR));
+}
+
/* Capture control
* Note: since mmixer->dests = 1, it means only playback control is visible
* This makes sense, because if there are no capture sources capture control
@@ -352,8 +363,10 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
++mline;
if (capt)
{
+FIXME("captelem found\n");
MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(captelem), -1, mline->name, sizeof(mline->name)/sizeof(WCHAR));
mline->component = getcomponenttype(snd_mixer_selem_get_name(captelem));
+FIXME("elem name: %s\n", snd_mixer_selem_get_name(captelem));
mline->dst = 1;
mline->capt = 1;
mline->elem = captelem;
@@ -361,6 +374,8 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
snd_mixer_elem_set_callback(captelem, &elem_callback);
snd_mixer_elem_set_callback_private(captelem, mmixer);
+} else {
+FIXME("no capt\n");
}
for (elem = snd_mixer_first_elem(mmixer->mix); elem; elem = snd_mixer_elem_next(elem))
@@ -395,6 +410,24 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
}
}
+static void filllines_no_master(mixer *mmixer, snd_mixer_elem_t *captelem, int capt)
+{
+snd_mixer_elem_t *elem;
+line *mline = mmixer->lines;
+
+FIXME("captelem found\n");
+MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(captelem), -1, mline->name, sizeof(mline->name)/sizeof(WCHAR));
+mline->component = getcomponenttype(snd_mixer
