(I CC:ed wine-devel, because some answers may interest some folks there too)
Vedran Rodic wrote:
Hi!
I've been playing a little with winmm dll. I would like to make the OSS sound devices runtime configurable (/dev/dsp, /dev/mixer and /dev/sequencer), and maybe make a wine alsa hardware driver implementation. I've encoutered a few issues, and I'm not making any steps without consulting you first since you wrote most of winmm code.
Regarding configuration of devices, I need it because my sound card (es1371) has an additional DAC mapped to /dev/dsp1, and I would like to make (or propose) a standard way to configure it for wine.
Currently I implemented it by adding calls to PROFILE_GetWineIniString to OSS_WaveInit and OSS_MidiInit. Now I have a problem that /dev/mixer string is defined in 3 different files, and I've been thinking about moving all PROFILE_GetWineIniString initialization to a separate file, and make calls to the function from that file in audio.c, mixer.c mmaux.c init functions.
when you say an additional DAC, it really means two different DACs (and not the same DAC accessed with different sets of parameters) if so, you don't need to use GetWineIniString. The most straightforward way of doing it is to implement multiple devices in wineoss/audio.c. Current code only tries to open /dev/dsp. It should try /dev/dsp1... (and so forth) if available. this should be simple to do: bump MAX_WAVEOUTDRV (and MAX_WAVEINDRV) and get the config code look for /dev/dsp for the first, /dev/dsp1 for the second...
With this, you'd be able to report several output (and input) channels for the same device
if it's in fact the same DAC, then that's more complicated...
I've been thinking about this .wine/config layout:
[wineoss.drv] "Wave"="/dev/dsp" "Mixer"="/dev/mixer" "Seqencer"="/dev/sequencer"
not needed, those are the regular OSS device drivers
Reharding alsa, I first have to be sure that I'll be able to select it over wineoss driver. I saw that wineoss hardware driver is installed in winmm/lolvldrv.c, but that needs a few PROFILE_GetWineIniString calls to MMDRV_Init.
this is going to go away. I'm finishing a patch where all drivers will be loaded from settings from the registry. So, if you write an ALSA driver (and, IMO there's a real need for such a driver), you'll just add some keys to the registry, and it'll be done (except that you'd need to define priorities between ALSA and OSS drivers, at configuration time)
I'm not entirely sure what to do about this section, because there can be more than two mappers in the futurem right?
[winmm] "HardwareDriver"="wineoss.drv" "Mappers"="msacm.drv, midimap.drv" ;; Could something like this be done?
Vedran Rodic
HTH
A+
On Tue, 20 Feb 2001, Eric Pouech wrote:
Vedran Rodic wrote:
Currently I implemented it by adding calls to PROFILE_GetWineIniString to OSS_WaveInit and OSS_MidiInit. Now I have a problem that /dev/mixer string is defined in 3 different files, and I've been thinking about moving all PROFILE_GetWineIniString initialization to a separate file, and make calls to the function from that file in audio.c, mixer.c mmaux.c init functions.
when you say an additional DAC, it really means two different DACs (and not the same DAC accessed with different sets of parameters)
Yes, the ES1371 compensates for its lack of any kind of synthesizer by adding an additional independent DAC. I think the extra DAC is meant to be used by a softsynth in the windows drivers or something.