Hi,
There's no $HOME/.asoundrc on any of my systems, yet I'd like to use "plug:dmix" with Wine, e.g. on systems with PulseAudio installed. I can use speaker-test -Dplug:dmix with no trouble. Will your patch make that appear in the list?
Нискородов Серёжа wrote:
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.
Avoiding snd_pcm_open is important. Right now, we already have tests that fail randomly because unfriendly devices like PulseAudio cling to the underlying resource ("hw:0") for a couple of seconds, preventing Wine from inspecting it (bug #28048), causing Wine IIRC to eliminate "hw:0" from the list of available devices. :-( That is not satisfying at all. Perhaps one easy shoot at it would be to access "default" last? That's still much like crossing fingers.
Thank you, Jörg Höhle
There's no $HOME/.asoundrc on any of my systems, yet I'd like to use "plug:dmix" with Wine, e.g. on systems with PulseAudio installed. I can use speaker-test -Dplug:dmix with no trouble. Will your patch make that appear in the list?
The devices that I can add to the list can be seen in output of "aplay -L". But I did not add devices with a colon in the title, because most of them are useless without extra "plug:" wrapper. I can add a wrapper "plug:" in front of them, but I think it's wrong. To be able to use your plug:dmix you can create .asoundrc, that contain: =-=-=-=-= pcm.dmixed { type plug slave { pcm "dmix" } } =-=-=-=-= Or something like this. And then you will see your device enumerated.
Avoiding snd_pcm_open is important. Right now, we already have tests that fail randomly because unfriendly devices like PulseAudio cling to the underlying resource ("hw:0") for a couple of seconds, preventing Wine from inspecting it (bug #28048), causing Wine IIRC to eliminate "hw:0" from the list of available devices. :-( That is not satisfying at all. Perhaps one easy shoot at it would be to access "default" last? That's still much like crossing fingers.
Seems like it is PulseAudio trouble much more than WINE or ALSA... In any case I don't like PulseAudio, and I don't use it.
On Friday, February 10, 2012 5:09:05 PM Нискородов Серёжа wrote:
There's no $HOME/.asoundrc on any of my systems, yet I'd like to use "plug:dmix" with Wine, e.g. on systems with PulseAudio installed. I can use speaker-test -Dplug:dmix with no trouble. Will your patch make that appear in the list?
The devices that I can add to the list can be seen in output of "aplay -L". But I did not add devices with a colon in the title, because most of them are useless without extra "plug:" wrapper. I can add a wrapper "plug:" in front of them, but I think it's wrong.
The only thing "plug:" would do that mmdevapi would need is sample type conversion. Wine will have to do some sample fiddling eventually anyway if it wants to support surround sound output (Windows and ALSA disagree on the channel ordering, so Wine needs to swap when writing between the app and ALSA; adding sample conversions on top of this shouldn't be hard). Plain mmdevapi can't do rate conversions or channel remixing and is up to the app, or other components sitting on top of mmdevapi, to do them.
FWIW, my custom dmix device for 5.1 Surround output shows up in aplay -L with a colon, as it's defined to accept arguments for the output device instead of hardcoding one, and neither plain 'dmix' or 'default' get listed. The only name without a colon is 'null'.
Ultimately, I can't say I'm a fan of snd_device_name_hint for enumerating devices. I get this from aplay -L:
null Discard all samples (playback) or generate zero samples (capture) front:CARD=NVidia,DEV=0 HDA NVidia, ALC888 Analog Front speakers surround40:CARD=NVidia,DEV=0 HDA NVidia, ALC888 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=NVidia,DEV=0 HDA NVidia, ALC888 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=NVidia,DEV=0 HDA NVidia, ALC888 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=NVidia,DEV=0 HDA NVidia, ALC888 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=NVidia,DEV=0 HDA NVidia, ALC888 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers iec958:CARD=NVidia,DEV=0 HDA NVidia, ALC888 Digital IEC958 (S/PDIF) Digital Audio Output dmix51:CARD=NVidia,DEV=0 HDA NVidia, ALC888 Analog Direct sample mixing device (5.1 Surround) dmix51:CARD=NVidia,DEV=1 HDA NVidia, ALC888 Digital Direct sample mixing device (5.1 Surround)
All but "dmix51:CARD=NVidia,DEV=0" is completely useless, and except for iec958, null, and the very bottom one, they all describe the same device (just with different output channel configs, which should be configured separately and not as a separate device entry)... and except for dmix51 and null, all will take exclusive use of the underlying device.
The only thing "plug:" would do that mmdevapi would need is sample type conversion.
Not only sample type, but sample rate to. For example, dmix plugin have predefined samplerate for mixing, so if WINE send other samplerate to it without "plug:" wrapper, in best case you will get error message and no sound.
FWIW, my custom dmix device for 5.1 Surround output shows up in aplay -L with a colon, as it's defined to accept arguments for the output device instead of hardcoding one, and neither plain 'dmix' or 'default' get listed. The only name without a colon is 'null'.
Seems like devices without a colon in names is only devices defined in /etc/asound.conf or in ~/.asoundrc
dmix51:CARD=NVidia,DEV=1 HDA NVidia, ALC888 Digital Direct sample mixing device (5.1 Surround)
All but "dmix51:CARD=NVidia,DEV=0" is completely useless
Do you can play wav mono 11025Hz directly to your dmix51 device? Without "plug:" wrapper? With my soundcard I can't.
So I can enumerate dmix*: devices to, I even can enumerate all devices, but I see almost no sence in this.
On Friday, February 10, 2012 10:50:33 PM Нискородов Серёжа wrote:
Not only sample type, but sample rate to. For example, dmix plugin have predefined samplerate for mixing, so if WINE send other samplerate to it without "plug:" wrapper, in best case you will get error message and no sound.
As I mentioned, native mmdevapi doesn't do samplerate conversion or channel remixing. For shared mode, the device only opens with a pre-defined, user- selected rate and channel config. The only thing the default native mmdevapi will do is accept different sample depths/type (prefering float32). It's up to the app or whatever component is using mmdevapi to convert to the rate/channels given by GetMixFormat.
Any other conversion besides sample type is reliant on the user having installed plugins that'll do the wanted conversion. If it really becomes an issue (which it shouldn't), Wine could support these and have some by default.
FWIW, my custom dmix device for 5.1 Surround output shows up in aplay -L with a colon, as it's defined to accept arguments for the output device instead of hardcoding one, and neither plain 'dmix' or 'default' get listed. The only name without a colon is 'null'.
Seems like devices without a colon in names is only devices defined in /etc/asound.conf or in ~/.asoundrc
My dmix51 device is defined in /etc/asound.conf. The difference is, it's defined to accept CARD, DEV, and SUBDEV parameters similar to regular dmix, so ALSA will enumerate it for each CARD and DEV that can support its output parameters.
dmix51:CARD=NVidia,DEV=1 HDA NVidia, ALC888 Digital Direct sample mixing device (5.1 Surround)
All but "dmix51:CARD=NVidia,DEV=0" is completely useless
Do you can play wav mono 11025Hz directly to your dmix51 device? Without "plug:" wrapper? With my soundcard I can't.
Nope, it won't open in a rate other than 48000hz without plug:. But again, that's fine for mmdevapi as it doesn't support rate conversion by default.
So I can enumerate dmix*: devices to, I even can enumerate all devices, but I see almost no sence in this.
What I'd suggest is using snd_card_next, snd_ctl_open (which won't lock the device like snd_pcm_open), snd_ctl_pcm_next_device, and related, to enumerate available card names and device indices, and have a configuration option in winecfg or somewhere to specify the prefix used ("dmix:", "plughw:", something custom, etc). Maybe another option to specify an additional list of custom devices that can't be detected this way, though most users shouldn't need that with the appropriate device prefix selected.
Just make sure to use the card name given by snd_ctl_card_info_get_id, so that the CARD parameter remains constant even if the card index changes.
As I mentioned, native mmdevapi doesn't do samplerate conversion or channel remixing. For shared mode, the device only opens with a pre-defined, user- selected rate and channel config. The only thing the default native mmdevapi will do is accept different sample depths/type (prefering float32). It's up to the app or whatever component is using mmdevapi to convert to the rate/channels given by GetMixFormat.
Any other conversion besides sample type is reliant on the user having installed plugins that'll do the wanted conversion. If it really becomes an issue (which it shouldn't), Wine could support these and have some by default.
I'm sorry, but I have no time to dive so deep and to study how mmdevapi works and how it have to work... So I cannot answer you.
My dmix51 device is defined in /etc/asound.conf. The difference is, it's defined to accept CARD, DEV, and SUBDEV parameters similar to regular dmix, so ALSA will enumerate it for each CARD and DEV that can support its output parameters.
Ok. I understand, I cannot ignore devices with colon in names.
Do you can play wav mono 11025Hz directly to your dmix51 device? Without "plug:" wrapper? With my soundcard I can't.
Nope, it won't open in a rate other than 48000hz without plug:. But again, that's fine for mmdevapi as it doesn't support rate conversion by default.
Hmm... Ok. But how it works in Windows? Does you mean that applications take care of sample rate conversion in Windows? Seems like it's not.
What I'd suggest is using snd_card_next, snd_ctl_open (which won't lock the device like snd_pcm_open), snd_ctl_pcm_next_device, and related, to enumerate available card names and device indices
Here is another trouble with snd_ctl_open. Not all devices in alsa configuration files have a predefined ctl. Especially defined by user, for example I don't always define a ctls for all my devices in .asoundconf So to use snd_ctl_open instead of snd_pcm_open I have to write some logic to fallback to hardware ctl if software device does not have own defined ctl. It's much more complicated, than I can do... At least for now.
, and have a configuration option in winecfg or somewhere to specify the prefix used ("dmix:", "plughw:", something custom, etc). Maybe another option to specify an additional list of custom devices that can't be detected this way, though most users shouldn't need that with the appropriate device prefix selected.
Just make sure to use the card name given by snd_ctl_card_info_get_id, so that the CARD parameter remains constant even if the card index changes.
I think you are greatly complicates this all. If all this devices can be enumerated and accessed by ALSA natively, then it all can be listed in WINE, why not? And user can select a device at his own risk. So what I suggest and what I can do for now: 1) To enumerate all devices, that ALSA can enumerate. First in list - default device (like it was before), after that - hardware devices (like it was before), and below all devices, that returns "aplay -L"; 2) To disable the testing of device avaliability (by alsa_try_open) while enumerating it. Thus, even devices that inaccessible at the time of enumeration can be added to the list. What you think about?
On Saturday, February 11, 2012 2:05:18 PM Нискородов Серёжа wrote:
Nope, it won't open in a rate other than 48000hz without plug:. But again, that's fine for mmdevapi as it doesn't support rate conversion by default.
Hmm... Ok. But how it works in Windows? Does you mean that applications take care of sample rate conversion in Windows? Seems like it's not.
That's how it works in Windows: http://msdn.microsoft.com/en- us/library/windows/desktop/dd370811%28v=vs.85%29.aspx "An application that uses WASAPI to manage shared-mode streams can rely on the audio engine to perform only limited format conversions. The audio engine can convert between a standard PCM sample size used by the application and the floating-point samples that the engine uses for its internal processing. However, the format for an application stream typically must have the same number of channels and the same sample rate as the stream format used by the device."
I remember seeing this happen with some of my own stuff in Windows, too.
Here is another trouble with snd_ctl_open. Not all devices in alsa configuration files have a predefined ctl. Especially defined by user, for example I don't always define a ctls for all my devices in .asoundconf
You can use the "hw:" prefix for snd_ctl_open. All you need it for is to get the card info and the available device indices, which doesn't rely on a custom prefix.
Hmm, actually it seems winealsa already does this enumerating. Except it hardcodes the plughw: prefix for the device string, uses the card index instead of the name, and doesn't explicitly specify the parameter names (it uses "x,y" instead of "CARD=x,DEV=y"). Perhaps I'll see about making some patches.
So what I suggest and what I can do for now:
- To enumerate all devices, that ALSA can enumerate. First in list -
default device (like it was before), after that - hardware devices (like it was before), and below all devices, that returns "aplay -L"; 2) To disable the testing of device avaliability (by alsa_try_open) while enumerating it. Thus, even devices that inaccessible at the time of enumeration can be added to the list. What you think about?
The problem with also taking everything shown by "aplay -L" is that it has a tendency to list the same device multiple times (which themselves are already mostly duplicated from the snd_card_next+etc enumeration, just with different prefixes). It can greatly increase the number of devices for no reason, IMO. You also can't get meaningful names from them (who would know what to make of it seeing "HDA NVidia, ALC888 Analog" and "HDA NVidia, ALC888 Digital" next to "HDA NVidia - ALC888 Analog" and "HDA NVidia - ALC888 Digital"?).
Registry options to skip device enumeration and to supply a custom list of devices will be fine, I think, as well as options to specify custom prefixes.
I'd agree with getting rid of alsa_try_open, unless there's a reason to keep it. I don't think there's a good reason to prevent enumerating the extra devices that can't be opened here though. It's status as unavailable/in-use can be handled later, I think.
On Sat, Feb 11, 2012 at 06:24:08AM -0800, Chris Robinson wrote:
On Saturday, February 11, 2012 2:05:18 PM Нискородов Серёжа wrote:
Here is another trouble with snd_ctl_open. Not all devices in alsa configuration files have a predefined ctl. Especially defined by user, for example I don't always define a ctls for all my devices in .asoundconf
You can use the "hw:" prefix for snd_ctl_open. All you need it for is to get the card info and the available device indices, which doesn't rely on a custom prefix.
Hmm, actually it seems winealsa already does this enumerating. Except it hardcodes the plughw: prefix for the device string, uses the card index instead of the name, and doesn't explicitly specify the parameter names (it uses "x,y" instead of "CARD=x,DEV=y"). Perhaps I'll see about making some patches.
Please, I would love to see how someone more familiar with ALSA would do this. My understanding is:
snd_ctl_name_hint() and friends: +Includes user-specified, non-hw devices as well as true hw devices, but: -Misses devices without 'hint' configs (Arch had this problem until a few weeks ago, other distros?) -Duplicates devices many times -Requires plughw: or other impossible-to-query prefix
snd_card_next() and friends: +Each device listed is listed only once, but: -Misses all user-specified, non-hw devices -Requires plughw: or other impossible-to-query prefix
User-specified device list: +Includes all devices a user wants, but: -Really sucks from a UI perspective
Each option has huge downsides. I would have guessed that name_hint() was the best choice, but you disagree with that, right?
I'd agree with getting rid of alsa_try_open, unless there's a reason to keep it. I don't think there's a good reason to prevent enumerating the extra devices that can't be opened here though. It's status as unavailable/in-use can be handled later, I think.
The reason was to prevent displaying broken or useless devices.
Another way to do it would be to report these devices, but fail to Initialize them with a more interesting error code (DEVICE_INVALIDATED or something) and handle that correctly in dsound, winmm, and the associated test suites (Jorg has a patchset that does most of this). Unfortunately, we'd potentially be presenting broken devices to the user, but I think it's probably better than trying to guess if a device is broken like we do now.
Andrew
snd_ctl_name_hint() and friends: +Includes user-specified, non-hw devices as well as true hw devices, but: -Misses devices without 'hint' configs (Arch had this problem until a few weeks ago, other distros?)
In my Ubuntu 11.04 snd_ctl_name_hint() lists all my devices, that I described in .asoundrc without 'hint' described.
On Monday, February 13, 2012 10:07:45 AM Andrew Eikum wrote:
On Sat, Feb 11, 2012 at 06:24:08AM -0800, Chris Robinson wrote:
Hmm, actually it seems winealsa already does this enumerating. Except it hardcodes the plughw: prefix for the device string, uses the card index instead of the name, and doesn't explicitly specify the parameter names (it uses "x,y" instead of "CARD=x,DEV=y"). Perhaps I'll see about making some patches.
Please, I would love to see how someone more familiar with ALSA would do this.
Not that I think I'm more familiar with ALSA, but what I do with OpenAL Soft is:
http://repo.or.cz/w/openal-soft.git/blob/e394d14cdab:/Alc/backends/alsa.c#l2...
My understanding is:
snd_ctl_name_hint() and friends: +Includes user-specified, non-hw devices as well as true hw devices, but: -Misses devices without 'hint' configs (Arch had this problem until a few weeks ago, other distros?) -Duplicates devices many times -Requires plughw: or other impossible-to-query prefix
snd_card_next() and friends: +Each device listed is listed only once, but: -Misses all user-specified, non-hw devices -Requires plughw: or other impossible-to-query prefix
User-specified device list: +Includes all devices a user wants, but: -Really sucks from a UI perspective
Each option has huge downsides. I would have guessed that name_hint() was the best choice, but you disagree with that, right?
Right. I think a combination of snd_card_next and a user-specified device list would be best.
I'd agree with getting rid of alsa_try_open, unless there's a reason to keep it. I don't think there's a good reason to prevent enumerating the extra devices that can't be opened here though. It's status as unavailable/in-use can be handled later, I think.
The reason was to prevent displaying broken or useless devices.
But just because it can't be opened on enumeration doesn't mean it can't be opened later. I think the point of enumeration should be to get what cards exist, not what cards are usable (that comes later).
What does native Windows do if an app enumerates devices while a sepeate app has a device opened in exclusive mode? That's the kind of behavior I'd expect here.
Another way to do it would be to report these devices, but fail to Initialize them with a more interesting error code (DEVICE_INVALIDATED or something) and handle that correctly in dsound, winmm, and the associated test suites (Jorg has a patchset that does most of this).
I suppose the actual error would be dependent on the error code from snd_pcm_open. A device that got removed since enumeration would be INVALIDATED, while a device that's simply busy would be IN_USE.
Here is another trouble with snd_ctl_open. Not all devices in alsa configuration files have a predefined ctl. Especially defined by user, for example I don't always define a ctls for all my devices in .asoundconf
You can use the "hw:" prefix for snd_ctl_open. All you need it for is to get the card info and the available device indices, which doesn't rely on a custom prefix.
It's Ok for hardware devices, but what about software devices?
The problem with also taking everything shown by "aplay -L" is that it has a tendency to list the same device multiple times (which themselves are already mostly duplicated from the snd_card_next+etc enumeration, just with different prefixes). It can greatly increase the number of devices for no reason, IMO. You also can't get meaningful names from them (who would know what to make of it seeing "HDA NVidia, ALC888 Analog" and "HDA NVidia, ALC888 Digital" next to "HDA NVidia - ALC888 Analog" and "HDA NVidia - ALC888 Digital"?).
Registry options to skip device enumeration and to supply a custom list of devices will be fine, I think, as well as options to specify custom prefixes.
Here is one small thing... You can not predict what devices are configured for me or someone else. So you cannot hardcode filter prefixes (like I do in first pacth version). So I suggest to list all available devices, but maybe to add in winecfg some checkboxes to display "dmix:", "hw:" or another... But I have no idea how it would look like...
I'd agree with getting rid of alsa_try_open, unless there's a reason to keep it. I don't think there's a good reason to prevent enumerating the extra devices that can't be opened here though. It's status as unavailable/in-use can be handled later, I think.
So i will write my patch to enum all available devices (include enumeration with snd_device_name_hint()) without using alsa_try_open? And you or someone can add filter options to winecfg.
On Monday, February 13, 2012 6:12:00 PM Нискородов Серёжа wrote:
Here is another trouble with snd_ctl_open. Not all devices in alsa configuration files have a predefined ctl. Especially defined by user, for example I don't always define a ctls for all my devices in .asoundconf
You can use the "hw:" prefix for snd_ctl_open. All you need it for is to get the card info and the available device indices, which doesn't rely on a custom prefix.
It's Ok for hardware devices, but what about software devices?
As long as you can set a custom prefix for the snd_pcm_open call, any device that can accept CARD and DEV parameters will work, whether it's hardware ("hw:", "plughw:"), software ("dmix:", "plug:dmix:"), or whatever.
For devices that can't, you'd explicitly list them in the registry. Since you've already gone through the trouble of writing up a custom ALSA device in .asoundrc, is it that much of a problem to also explicitly tell Wine about it? It's not something normal users do, but for "power users" I don't see a problem with asking them to tell Wine about it.
Though I wouldn't be opposed to having a driver-specific configuration GUI where this could be written too, to avoid regedit.
Here is one small thing... You can not predict what devices are configured for me or someone else.
Nor can you predict how much junk snd_device_name_hint will give. Since snd_device_name_hint requires the user to go out of their way to be useful (i.e., edit .asoundrc to get their device defined and listed, and delist unwanted devices), I don't think it's that useful to have for normal users.
Hi,
Chris Robinson wrote:
All but "dmix51:CARD=NVidia,DEV=0" is completely useless, and except for iec958, null, and the very bottom one, they all describe the same device
Now we've done a full circle. My feeling past bug #28723 comment #110 http://bugs.winehq.org/show_bug.cgi?id=28723#c110 was that ALSA's enum functions are useless and bound to display more junk than useful devices (perhaps even causing Wine's initialization to slow down as it accesses half a dozen useless or non-working devices).
Bottom line IMHO: 1. Wine-1.4 MUST have a means to select something other than "default" without recompiling. 2. Via registry or winecfg, I don't mind.
A stupid registry entry would be fine with me. At least, winecfg would remain void of GUI logic that's valid for winealsa only. Unless you go the DRV_CONFIGURE route and add extra "extended..." or "configure..." buttons that'll call into a GUI supplied by the component (you may know that from codec configuration windows).
In winecfg, a free-form text entry box would be enough with me. I'd write "plug:dmix" there. I have not yet seen any of the enumeration functions yield that name, so I don't believe in enumeration.
Regards, Jörg Höhle
Bottom line IMHO:
- Wine-1.4 MUST have a means to select something
other than "default" without recompiling. 2. Via registry or winecfg, I don't mind.
A stupid registry entry would be fine with me. At least, winecfg would remain void of GUI logic that's valid for winealsa only. Unless you go the DRV_CONFIGURE route and add extra "extended..." or "configure..." buttons that'll call into a GUI supplied by the component (you may know that from codec configuration windows).
In winecfg, a free-form text entry box would be enough with me. I'd write "plug:dmix" there. I have not yet seen any of the enumeration functions yield that name, so I don't believe in enumeration.
I really don't understand you. Why to write "plug:dmix" in wine, while you can configure ALSA devices natively via .asoundrc ? Or are you write "plug:dmix" manually in all your applications, that use sound output?
Hi,
Нискородов Серёжа wrote:
I really don't understand you. Why to write "plug:dmix" in wine, while you can configure ALSA devices natively via .asoundrc ?
plug:dmix is 9 characters, .asoundrc not well documented, with features that even people who've been writing them for long can learn any day, e.g. the influence of the "hint" field.
You're right that plug:dmix is not a good device, because it cannot capture.
Or are you write "plug:dmix" manually in all your applications, that use sound output?
No, Wine is the only one where I'm regularly testing dmix behavior instead of PulseAudio. All I want is the thing that "default" is in the absence of "pulse". That thing can do capture and playback.
The new "sysdefault" ALSA name is what I'd need, but it's too new for Ubuntu Intrepid or Lucid.
Because if tomorrow I will add a new device to .asoundrc, I will also have to add it to the WINE registry?
Registry or winecfg, is there such a difference?
What I observe is: The current device enumeration causes unusable devices, because some "meta devices" like "pulse" prevent accessing the underlying device hw:0 for 5 seconds. That is bug #28048.
Simple approach to avoid that: 1. Use only hw:* and "default" (or the registry override). 2. Try not to access "default" unless needed (perhaps last). 3. Try and gather information about the devices without "accessing" them. 4. Display information and let user choose one in winecfg. Winecfg should display the name of the current override, if any. A sort of "worse is better" approach.
Andrew Eikum's patch could be extended to parse a comma separated list of ALSA device names.
Elaborated approach: 1. Find a way to enumerate devices -- what way? Did you all agree on snd_ctl_name_hint? OpenAL uses snd_card_next 2. Try not to list identical devices multiple times -- how? 3. and 4. As above
I'm not opposed to the elaborate approach. I just don't want it to cause bugs and obscure behavior (like app A manages to open hw:0 because it tries it more than 5 seconds after "default", whereas app B fails because it tries immediately). My fear: the longer the list of devices, the more trouble there will be.
I should not fear that SW breaks. I want to be confident that it works.
Regards, Jörg Höhle
Because if tomorrow I will add a new device to .asoundrc, I will also have to add it to the WINE registry?
Registry or winecfg, is there such a difference?
Difference is that I have to describe the device in wine while this device is already described in .asoundrc.
Elaborated approach:
- Find a way to enumerate devices -- what way?
Did you all agree on snd_ctl_name_hint? OpenAL uses snd_card_next 2. Try not to list identical devices multiple times -- how? 3. and 4. As above
What about adding registry parameter (or winecfg checkbox) to select when user want to list software devices (with snd_ctl_name_hint()). Then users who know what device is what can see all devices. Seems like I can write this (registry parameter, not checkbox) ))
Chris Robinson wrote:
It's not something normal users do, but for "power users" I don't see a problem with asking them to tell Wine about it.
I'm a power user, but for what I have to wrote device name in regedit, if I can just select it from the list? What you think about my suggestion above?
On Monday, February 13, 2012 8:37:42 PM Нискородов Серёжа wrote:
Chris Robinson wrote:
It's not something normal users do, but for "power users" I don't see a problem with asking them to tell Wine about it.
I'm a power user, but for what I have to wrote device name in regedit, if I can just select it from the list?
Getting a sane list from ALSA is the problem. If there was a way to get purely user-defined devices (excluding front, surround*, iec958, null, etc, unless the user has explicitly configured them to be listed) that would be one thing, but as it is, ALSA's enumeration methods leave a lot to be desired.
For now, I think snd_card_next, with registry options for custom prefixes and an additional set of devices, is the best way to go. There's simply too much junk with snd_ctl_name_hint.
In the long run, I think ALSA itself needs better device management. I have some ideas for this, like a new prefix to follow per-device configurations (i.e., so an app can open "whatever:CARD=name,DEV=index", and ALSA will automatically use a user-defined card/index-specific configuration). Virtual devices that a user has defined via .asoundrc would be enumerated as their own cards with one device index (i.e., it would be enumerated as a normal card, and instead of opening "custom" you'd open "whatever:CARD=custom,DEV=0").
That, or something like that, would of course require changes to ALSA, but I think it would ultimately benefit everyone.
2012/2/13 Chris Robinson chris.kcat@gmail.com:
On Monday, February 13, 2012 8:37:42 PM Нискородов Серёжа wrote:
Chris Robinson wrote:
It's not something normal users do, but for "power users" I don't see a problem with asking them to tell Wine about it.
I'm a power user, but for what I have to wrote device name in regedit, if I can just select it from the list?
Getting a sane list from ALSA is the problem. If there was a way to get purely user-defined devices (excluding front, surround*, iec958, null, etc, unless the user has explicitly configured them to be listed) that would be one thing, but as it is, ALSA's enumeration methods leave a lot to be desired.
Ok, I agree, many "junk devices", bad enumeration methods, okay. But why you are against a registry parameter? I'm a power user, I know WHAT I do, I want to see all ALSA devices, even "junk". Why I can't do that? I will ONE time go to regedit and set this parameter "Enumerate all devices", and always will see my favorite devices from .asoundrc, even new added. But you want to do it more difficulty, when I define a new device in .asoundrc, I have to write it's name to WINE registry.
On Monday, February 13, 2012 10:31:06 PM Нискородов Серёжа wrote:
Ok, I agree, many "junk devices", bad enumeration methods, okay. But why you are against a registry parameter? I'm a power user, I know WHAT I do, I want to see all ALSA devices, even "junk". Why I can't do that?
Mainly because it's just another way with which users can mess up their configuration. Options are good for forcing specific values when default detection fails or is sub-optimal. But options for new behavior that's not needed (and brings in unwanted side effects, e.g., duplicate and unuseable audio devices) just adds unnecessary variability to the code's behavior.
IMO, of course. It's not just you and me that need to worry about such an option, but all the users that have access to it and all the developers that need to deal with the consequences.
But you want to do it more difficulty, when I define a new device in .asoundrc, I have to write it's name to WINE registry.
I'm not the arbiter of what winealsa will or will not do. I'm just giving my thoughts and opinions on the matter.
On Mon, Feb 13, 2012 at 12:08:57PM -0800, Chris Robinson wrote:
For now, I think snd_card_next, with registry options for custom prefixes and an additional set of devices, is the best way to go. There's simply too much junk with snd_ctl_name_hint.
I agree with this analysis. Here's a patch. It uses pipes to separate device names, since I know commas are meaningful in ALSA. Perhaps that's not enough, and we need to do quoting?
In any case, this patch ought to be enough to satisfy users for 1.4. Any thoughts, anyone?
Andrew
I agree with this analysis. Here's a patch. It uses pipes to separate device names, since I know commas are meaningful in ALSA. Perhaps that's not enough, and we need to do quoting?
In any case, this patch ought to be enough to satisfy users for 1.4. Any thoughts, anyone?
AFAIK, pipes is enough, and your patch works for me.
Andrew Eikum aeikum@codeweavers.com writes:
I agree with this analysis. Here's a patch. It uses pipes to separate device names, since I know commas are meaningful in ALSA. Perhaps that's not enough, and we need to do quoting?
The right way would be to use a MULTI_SZ string.
Hi,
Chris Robinson wrote:
You forgot AUDCLNT_STREAMFLAGS_RATEADJUST since w7.
Interestingly, this flag seems to only have an effect for already-initialized streams. ALSA would need a way to adjust the rate of an opened device for this to work.
My view on it is this: given that it's said to work in shared mode only, I believe it gives limited access to MS' internal resampler device. Output is still driven at the mixer's nomimal rate, there's no need to adjust the rate of an open ALSA back-end.
IOW, if you were to implement winmm on top of mmdevapi in w7, here's what you'd do: . Call Activate . Call GetMixFormat . If rate is different from requested, add AUDCLNT_STREAMFLAGS_RATEADJUST . call Initialize . If rate is different, call SetSampleRate
The native resampler adjusts the rates, the mixer adjusts bit width and whatever entity adjusts the channel mapping (formerly the NT kernel mixer was said to do that).
I suppose MS' mmdevapi behaves like gstreamer as a sequence of audio filters and converters. If you ask for a rate resampler, it'll plug one into the chain. Plugging can only be performed at initialization time, there's no further dynamic reconfiguration.
That's why I'll repeat once more and say that DSound's resampler should become that one.
My little knowledge about DSound's 3 initialisation modes (WRITE_PRIMARY etc.) tells me it's compatible with such a scheme: there are restriction on when you're allowed to invoke SetFormat on the Primary buffer.
Regards, Jörg Höhle
On Wednesday, February 22, 2012 11:42:13 AM Joerg-Cyril.Hoehle@t-systems.com wrote:
That's why I'll repeat once more and say that DSound's resampler should become that one.
My little knowledge about DSound's 3 initialisation modes (WRITE_PRIMARY etc.) tells me it's compatible with such a scheme: there are restriction on when you're allowed to invoke SetFormat on the Primary buffer.
DSound needs to resample itself anyway, to mix all the secondary buffers to the output stream. If winmm streams are implemented using secondary buffers on dsound, then there's no issue with making resampling as dsound will do it.
I'd also wager that DSound's primary buffer is largely faked. It's telling that the primary buffer is (in tests Maarten and I have done) always 32768 bytes, even for output modes where that isn't a multiple, or where it can only hold 20ms of audio.
I would say IDirectSoundBuffer::SetFormat accepts reasonable any rate, although it outputs using the mmdevapi device rate, and WRITE_PRIMARY emulates primary access by using a secondary buffer, which can be set to the specified rate.
On Mon, Feb 13, 2012 at 02:12:02PM +0100, Joerg-Cyril.Hoehle@t-systems.com wrote:
Bottom line IMHO:
- Wine-1.4 MUST have a means to select something other than "default" without recompiling.
- Via registry or winecfg, I don't mind.
A stupid registry entry would be fine with me.
Here's a stupid registry entry patch. The paths are: HKCU\Software\Wine\Drivers\winealsa.drv\ALSAOutputDevice HKCU\Software\Wine\Drivers\winealsa.drv\ALSAInputDevice
If we can't reach a sensible consensus about device enumeration sometime this week, I'll submit this to fix 1.4.
Andrew
Here's a stupid registry entry patch. The paths are: HKCU\Software\Wine\Drivers\winealsa.drv\ALSAOutputDevice HKCU\Software\Wine\Drivers\winealsa.drv\ALSAInputDevice
If we can't reach a sensible consensus about device enumeration sometime this week, I'll submit this to fix 1.4.
I do not agree with this approach. Because if tomorrow I will add a new device to .asoundrc, I will also have to add it to the WINE registry? Of course it will work, but it is far easier to select the available device from list, even if in that list is more devices than necessary.
Hi,
Нискородов Серёжа wrote:
Do you can play wav mono 11025Hz directly to your dmix51 device? Without "plug:" wrapper? With my soundcard I can't. So I can enumerate dmix*: devices to, I even can enumerate all devices, but I see almost no sence in this.
My Ubuntu dmix can't either. All it accepts is 48000 two channel 32bit(!) integer PCM. You can check with speaker-test -Ddmix -c2 ...
Chris Robinson wrote:
Plain mmdevapi can't do rate conversions
You forgot AUDCLNT_STREAMFLAGS_RATEADJUST since w7.
As I mentioned, native mmdevapi doesn't do samplerate conversion or channel remixing. For shared mode, the device only opens with a pre-defined, user- selected rate and channel config. The only thing the default native mmdevapi will do is accept different sample depths/type (prefering float32).
Right. Have a look at dlls/mmdevapi/tests/render output: http://test.winehq.org/data/tests/mmdevapi:render.html A very typical result is: render.c:409: IsSupported(exclus., 44100x16x2) render.c:409: IsSupported(exclus., 48000x16x2) render.c:409: IsSupported(shared , 44100x 8x2) render.c:409: IsSupported(shared , 44100x16x2) The HW supports solely 2 channel 16bit stereo but both 44100 and 48000fps. In the system's audio preferences dialog, the user has selected 44100. That's why GetMixFormat returns that rate. In addition, the shared mode mixer accepts 8bit -- but not mono! IOW, it converts 8 and 16bit samples to its internal floating point format. 48000 gets refused based on the user's selection.
It's up to the app or whatever component is using mmdevapi to convert to the rate/channels given by GetMixFormat.
This is misleading in the context of Wine. As I've laid down in http://wiki.winehq.org/Sound?highlight=(Limitations) Wine depends on a non-conforming mmdevapi that accepts all possible formats such as 7192x8x1 for its winmm and DSound to work. That's also why it uses plughw:0 instead of hw:0 when not using "default".
Since Vista, dlls/winmm/tests/wave reports formats=fffff i.e. all formats supported. So there is something between native's winmm and mmdevapi that converts all of those. In Wine, there's nothing. Wine expects the ALSA/OSS/CoreAudio back-end to do that. (that is why I've argued that DSound's resampler should be part of mmdevapi instead such that all Wine components could use it).
Regards, Jörg Höhle
On Monday, February 13, 2012 2:17:13 PM Joerg-Cyril.Hoehle@t-systems.com wrote:
Chris Robinson wrote:
Plain mmdevapi can't do rate conversions
You forgot AUDCLNT_STREAMFLAGS_RATEADJUST since w7.
Interestingly, this flag seems to only have an effect for already-initialized streams. ALSA would need a way to adjust the rate of an opened device for this to work.
It's up to the app or whatever component is using mmdevapi to convert to the rate/channels given by GetMixFormat.
This is misleading in the context of Wine. As I've laid down in http://wiki.winehq.org/Sound?highlight=(Limitations) Wine depends on a non-conforming mmdevapi that accepts all possible formats such as 7192x8x1 for its winmm and DSound to work.
Wine's dsound needs to do its own resampling and mixing to handle secondary buffers, so it should be able to output whatever rate mmdevapi wants. If winmm outputs through dsound, and dsound outputs through mmdevapi, then neither should have a problem with mmdevapi accepting only one rate.
-
Alexandre Julliard -
Andrew Eikum -
Chris Robinson -
Joerg-Cyril.Hoehle＠t-systems.com -
Нискородов Серёжа