[PATCH 1/4] winealsa: Move get_prop_value to the unixlib.

[Emil Velikov]

On Tue, 15 Mar 2022 at 08:56, Huw Davies <huw at codeweavers.com> wrote:
>
> On Tue, Mar 15, 2022 at 08:38:32AM +0000, Emil Velikov wrote:
> > Have you considered splitting the props handling - get_device_path,
> > get_physical_speakers?
> > AFAICT this should reduce the duplication on the unix side (alsa vs
> > pulse vs others). More importantly it makes it easier to avoid the
> > caller allocated string, by passing the vendor/device/other data
> > directly.
>
> We could split these, but I didn't want the number of syscalls
> to escalate.  If there really are only two properties then
> that doesn't sound too bad.
>
Are there any technical implications of having say 10 vs 20 syscalls
or is it mostly to preserve one's sanity?
The syscall lookup machinery should not care, unless we're talking
about orders of magnitude.

> > What are your thoughts on having a single mmdev.drv, which calls into
> > winealsa.drv/winepulse.drv/other? Are wineandroid/mmdev, winecoreaudio
> > and wineoss in scope in the mid/long run?
>
> Yes, long term the aim would be to have a single PE-side.  I've been
> keeping the unixlib interfaces as close as possible to facilitate this.
> Once all of the drivers are done, we'll had a good idea of what that'll
> look like.
>
> winecoreaudio is already done and I've started on wineoss, though
> I still have the midi bits of winealsa to upstream.
>
Very nice.

Speaking of midi bits:
Which version of Windows deprecates(?) winmm.dll and/or the multimedia
extensions MME?

> Until you'd mentioned it, I'd forgotten about sound side of
> wineandroid, so I guess that's one more to do :-(
>
^W^W^W^W^W I didn't say anything :-P

Keep up the good work.
-Emil