writes:
> Alexandre Julliard wrote:
>>If PulseAudio can't provide good enumeration, then we can detect
>>that case and handle it differently.
> We don't ask PA to enumerate, we ask ALSA to enumerate.
I know that. It doesn't mean we can't use a heuristic to detect broken
PA enumeration.
>>My us
Alexandre Julliard wrote:
>If PulseAudio can't provide good enumeration, then we can detect
>that case and handle it differently.
We don't ask PA to enumerate, we ask ALSA to enumerate.
Remembers me of the difficulties of enumerating /dev in Linux from user space:
The problem is similar: open an
writes:
> Alexandre Julliard wrote:
>>At least on my setup, the current code is working just fine, and offering
>>the devices I expect, without any manual configuration.
> Are you using PulseAudio?
> I believe that *every* user with PulseAudio is bound to see the flakiness
> that happened on Fra
On Tue, 22 Jan 2013, joerg-cyril.hoe...@t-systems.com wrote:
[...]
> We see 3 types of results
> 2x: 2 devices, no ALSA "default" device(!), one HDA-An, one HDA-HDMI
> 1x: 3 devices incl. ALSA "default", all tests successful
> 1x: 3 devices incl. ALSA "default", dev. 1 HDA-An yields MMSYSERR_ALLOCA
Alexandre Julliard wrote:
>At least on my setup, the current code is working just fine, and offering
>the devices I expect, without any manual configuration.
Are you using PulseAudio?
I believe that *every* user with PulseAudio is bound to see the flakiness
that happened on Francois' machine. So
Andrew Eikum writes:
> On Tue, Jan 22, 2013 at 11:15:59AM +0100, joerg-cyril.hoe...@t-systems.com
> wrote:
>> Andrew Eikum was in favour of this too and since implemented winmm
>> device notification upon change. Remember the December thread:
>> http://www.winehq.org/pipermail/wine-devel/2012-D
On Tue, Jan 22, 2013 at 11:15:59AM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> Andrew Eikum was in favour of this too and since implemented winmm
> device notification upon change. Remember the December thread:
> http://www.winehq.org/pipermail/wine-devel/2012-December/098114.html
>
Yeah,
Hi,
please view the winmm:wave test results from Francois Gouget's machines
fg-acer64-t32 fg-acer64-wow32
fg-acer64-t64 fg-acer64-wow64
http://test.winehq.org/data/dabde6a04f6d02233bc5074a8eba613b2c4adc68/index_Linux.html#winmm:wave
Is their configuration the same except for 32/64bit?
We see 3 t
On 12/11/2012 08:46 AM, Henri Verbeet wrote:
On 11 December 2012 16:05, wrote:
Cost to users:
Users with a working ALSA device "default" should experience no
drawback, only benefits. I believe this is the vast majority of users.
Users that edit their ~/.asoundrc to define other devices with
On Wed, Dec 12, 2012 at 04:45:11PM +0100, Henri Verbeet wrote:
> On 12 December 2012 16:31, Andrew Eikum wrote:
> > Even ignoring the Pulse case, we don't have an acceptable enumeration
> > API.
> Yes, I know. I just don't think it would be unreasonable to try to
> work with ALSA upstream to fix t
On 12 December 2012 16:31, Andrew Eikum wrote:
> Even ignoring the Pulse case, we don't have an acceptable enumeration
> API.
Yes, I know. I just don't think it would be unreasonable to try to
work with ALSA upstream to fix that.
On Wed, Dec 12, 2012 at 03:57:40PM +0100, Henri Verbeet wrote:
> On 12 December 2012 15:28, Andrew Eikum wrote:
> > It's tricky because ALSA and PulseAudio have different theories about
> > where device selection should occur -- in the application or in the
> > audio mixer. In the ALSA case, we wa
On Wed, Dec 12, 2012 at 04:23:52PM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> Max TenEyck Woodbury objected:
> >Replacing the ability to use a drop box in the app to select the audio
> >device with a 'regedit' session is not an improvement.
> My proposal intentionaly was silent about GUI cha
On 12 December 2012 16:23, wrote:
> Henri Verbeet suggested:
>>But supposedly we'll have a winepulse driver eventually, so winealsa
>>would only need to care about actual ALSA devices.
> Alas, it's only after you opened the device that you can discover that
> it's PulseAudio, at which time it is
Hi,
Henri Verbeet suggested:
>But supposedly we'll have a winepulse driver eventually, so winealsa
>would only need to care about actual ALSA devices.
Alas, it's only after you opened the device that you can discover that
it's PulseAudio, at which time it is too late.
Also, I don't know if PA is t
On 12 December 2012 15:28, Andrew Eikum wrote:
> It's tricky because ALSA and PulseAudio have different theories about
> where device selection should occur -- in the application or in the
> audio mixer. In the ALSA case, we want to list devices. In the Pulse
> case, we want to list only "default"
On Tue, Dec 11, 2012 at 04:46:34PM +0100, Henri Verbeet wrote:
> On 11 December 2012 16:05, wrote:
My first reaction is that this is a good idea. We've had some
discussion about device enumeration before. The final conclusion was
it's basically impossible to do usefully with ALSA. I can't think
On 12/11/2012 02:11 PM, Austin English wrote:
On Tue, Dec 11, 2012 at 9:39 AM, Max TenEyck Woodbury
wrote:
On 12/11/2012 10:46 AM, Henri Verbeet wrote:
It will also pretty much just remove device selection on setup with
multiple audio devices, which is actually fairly common these days
with U
On Tue, Dec 11, 2012 at 9:39 AM, Max TenEyck Woodbury
wrote:
> On 12/11/2012 10:46 AM, Henri Verbeet wrote:
>>
>> On 11 December 2012 16:05, wrote:
>>>
>>> Cost to users:
>>>
>>> Users with a working ALSA device "default" should experience no
>>> drawback, only benefits. I believe this is the v
On 12/11/2012 10:46 AM, Henri Verbeet wrote:
On 11 December 2012 16:05, wrote:
Cost to users:
Users with a working ALSA device "default" should experience no
drawback, only benefits. I believe this is the vast majority of users.
Users that edit their ~/.asoundrc to define other devices with
On 11 December 2012 16:05, wrote:
> Cost to users:
>
> Users with a working ALSA device "default" should experience no
> drawback, only benefits. I believe this is the vast majority of users.
>
> Users that edit their ~/.asoundrc to define other devices without
> simultaneously overriding !defau
Hi,
Here's my proposal:
winealsa shall stop enumerating ALSA devices. By default, it should
solely provide access to ALSA's default device adequately named "default".
The code that currently scans the registry
Software\Wine\Drivers\winealsa.drv\devices=... shall remain in place,
allowing a comm
22 matches
Mail list logo
