winealsa.drv patch to enum all software devices from .asoundrc

Нискородов Серёжа sghpunk at
Thu Feb 9 14:08:39 CST 2012

> Thanks, I've been wanting to do this for a while. I've been hesitating
> because ALSA doesn't document the format of their device names. If a
> device name contains a colon, is it _always_ a hardware device that
> will be returned by the snd_card_* family? Who knows...

To check whether the device is a hardware, I can call a function
snd_pcm_type. But first I need to get handle of pcm device using the
snd_pcm_open. Okay, but then I have to cancel calling the function
alsa_try_open and rewrite checking availability of the device to not
to opening it twice... Or maybe rewrite function alsa_try_open to
return a snd_pcm_type_t?
Huh ... I decided to just check for the presence of a colon in the
name of the device. So it was easier.

> You can probably come up with a better name than "n" ("hint"? "cur"?).

Heh )) This code was copied from aplay source code with variable
names. But you are right, I will rename a variable.

> Why do you create stream2? It looks like stream does what you wanted
> already.

Honestly, I just do not understand the syntax of its assignment. So I
just copied stream variable from aplay source to.

>> +            if(strstr(name, ":") != NULL )
>> +                goto __end;
>> +            if (io != NULL && strcmp(io, filter) != 0)
>> +                goto __end;
> Instead of using goto, just use regular if/else. You may have to
> indent everything once more, but that's fine.

This goto was copied from aplay source to ))
Ok. I will try to rewrite this code.

>> +                    ids[*num] = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR));
>> +                    if(!ids[*num]){
>> +                        return E_OUTOFMEMORY;
>> +                    }
> Doing correct cleanup after HeapAlloc() failure is complicated here.
> Since things are going to crash badly if HeapAlloc() fails anyway, I
> think you can just assume success and get rid of the error checking.

Are you sure? This piece of code was taken from function
alsa_get_card_devices() (mmdevdrv.c), I just copied the way of
assigning and checking for errors. I think if the check is performed
there, I also have to fulfill it.

>> +            if (name != NULL)
>> +                free(name);
> free() checks for NULL anyway, so the if() is not needed.

This is from aplay source to. ))
Ok. I will correct this.

> If snd_device_name_hint() fails, you should print a WARN message so we
> can know if something went wrong.

You think this is really necessary? If snd_device_name_hint() fails, I
just skip of enumeration of software devices. Does it really need to
print WARN message here?

> And finally, you should use snd_device_name_free_hint(hints) to clean
> up those resources.

Yes, I just forget about it.

> One more thing, this messes up the default device selection, which
> remains hard-coded for the first device. I'd suggest something like
> the following to add to your patch. It chooses "default" as the
> default device, or "pulse" if that doesn't exist.

The point is that the device "default" is already listed with the
function snd_device_name_hint (). So I thought it unnecessary to add a
device "default" in the first place, and deleted the code. After all,
if you select in winecfg "(System default)" then in any case, the
sound goes to the"default" device.Or am I wrong?

> It's not bad at all! After fixing the little stuff above, you can send
> it to wine-patches yourself. Please read
> <>;

Thanks for your support. ))
I read it, but there are so many instructions, I'm afraid to make a
mistake in some ...

By the way, I have created a bug on

> your wine-devel mail was
> not formatted correctly.

I was trying to Follow all instructions. What is my mistake?

And one more question for the mailing list. Why did not I received my
first letter, though in the settings of the mailing list stands to
receive? If it's because of my mistake in formatting, how you received

More information about the wine-devel mailing list