Add more improvements and fixes to volume control implementation.
- Don't allocate and don't use an array for storing volume level values. Also, get rid from some stuff, which is not used any more (some fields of MIXERVOLUME_DATA structure and MMixerGetVOlumeControlIndex() function).
- Use the following formulas to properly convert the volume level values from the logical units range (0 - 65535) to the hardware Decibel (DB) range (defined by audio miniport driver): <decibels> = <units> * <range_in_db> / <range_in_units> + <minimal_level> (for setting the new value) and <units> = (<decibels> - <mimimal_level> + 1) * <range_in_db> / <range_in_units> (for getting the previous value), where <decibels> is a DB hardware value, <units> is logical units value, <rang_in_db> is the hardware range (DB), <range_in_units> is range in the logical units and <minimal_level> is the most minimum volume level value defined by an audio miniport driver.
- I've created this formula myself basing on my calculations and investigations (with some help from Hermes Belusca-Maito), so it's tested and confirmed to be working for all possible values range (at least for our official Intel AC97 driver, and, as tested later, Realtek HD audio).
- Do this in both cases when setting the new and when getting the previous volume value as well.
- Fallback to default values range -96 - 0 DB in case either the volume level property is not supported by audio miniport driver, or the values range is empty (SignedMinimum is equal to SignedMaximum and both of them typically have a 0 (zero) value). Realtek HD audio codec is one of such a drivers, so this fixes the volume control on real hardware too (tested on Asus-F5R notebook with Realtek ALC660 audio controller). Moreover, the volume values set by user are even properly saved (aren't lost) after reboot (unlike with Intel AC97 in VirtualBox or SoundBlaster in VMware)! Realtek probably uses another mechanism to write/read the value(s) to/from Registry, which is handled by the miniport (codec) driver instead.
This fixes some remaining bugs when changing the volume level, so now 1) min/max position of the volume bar can be reached correctly and 2) left/right balance sliders are now behaving properly (they don't affect position of each other anymore when moving them manually).
CORE-19189, CORE-19190
This is actually a hack and isn't required anymore because I made a proper fix instead.
Doing -1 does not fix the problem correctly, but only makes a pseudo-effect that it's fixed by actually truncating each volume value, so then the volume sliders misbehaving does occur less (but it still does).
This reverts commit 206b52833f.
CORE-19190
[SDK][WDFLDR] Add kmdf loader driver
[SDK][WDF] Add kmdf drver init static library
[SDK][WDF] Modify kmdf driver for working with wdfldr driver
[SDK][CDROM] Cdrom driver dynamically linking with kmdf
[SDK][WDF] Add kmdfdriver module type
[SDK][WDF][USBDEX][NTOSKRNL_VISTA] Fully enable KMDF
[KMDF][WDFLDR][WDF01000] Fix Windows 10 Compatibility WDFLDR and WDF01000
[WDF01000] NO_KERNEL_LIST_ENTRY_CHECKS for wdf01000 3rd party code
This PR is an accumulation of three peoples work, with the goal of the trying to get WDF to work like it should.
This has been tested in combination with some extra NT6+ ntoskrnl against multiple drivers.
---------
Co-authored-by: Max Korostil <mrmks04@yandex.ru>
Co-authored-by: Victor Perevertkin <victor.perevertkin@reactos.org>
Co-authored-by: Adam Słaboń <asaillen@protonmail.com>
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
Add a SCSI and ATA passthrough support helper library for direct use
from low-level storage drivers.
Tested with: CDRoller, CloneCD, Magic ISO
NOTE: Vbox seems to lack support for CD/DVD burning; tested on real hardware.
CORE-10191 CORE-16452
CORE-14788 CORE-18241
CORE-17256 CORE-13866
This workarounds broken changing volume level for left and right volume controls separately ("Speakers Volume" button in "Sound" tab of mmsys.cpl).
CORE-19190
Fix broken volume level changing and left/right speakers balance level changing.
Get and set volume level value for all available output channels instead of only the 1st channel (available in MIXERCONTROLDETAILS.cChannels member), so other channels don't have a non-set volume values now. This allows to control the volume for all channels.
So now the volume control works correctly and hence, the volume level can be properly changed from Sound Properties (mmsys.cpl) and Volume Mixer (sndvol32.exe) as well.
Note that the volume level settings changed by user are not saved after reboot yet. We need to save (write) and then load (read) them at next boot from HKLM/System/CurrentControlSet/Control/DeviceClasses/KSCATEGORY_AUDIO/.../DeviceParameters/Mixer/.../* keys inside wdmaud.sys, similarly to as it's done in Windows XP/2003. It can be tested (and is tested sveral times by me and is confirmed) by using MS wdmaud.sys in ReactOS. It writes the values in that key, so the actual volume values are stored there.
Another key, HKCU/SOFTWARE/Microsoft/Windows/Applets/Volume Control/, is created and managed by sndvol32.exe instead, so it does not contain the actual values of volume levels.
CORE-17976
Skip unsuccessfully initialized devices and continue enumeration until all of devices are enumerated.
Patch by Johannes Anderwald with additional improvements from me.
This fixes 0 audio devices detected for HD audio controllers (e. g., Realtek), and hence allows to properly detect all available devices and play the sound with MMixer routines enabled (they are currently default).
Tested personally with Realtek HD Audio driver version R2.74 for Windows XP/Server 2003 in pair with hdaudbus.sys from Windows Vista SP2 on real hardware.
CORE-17285
URLs are getting old. We have to
update URLs for documentation
purpose.
JIRA issue: CORE-19963
- Refresh old URLs.
- Add " (DEAD_LINK)" labels
to dead links.
- Use MS Learn links rather
than MSDN ones.
- Some dead links revived by
Web Archive.
- Don't change Wine Tests
and Wine Sync.
- Don't change 3rd party libraries.
- Don't append "redirected" labels.
- Add bugcodes dependency, fixes a rare build failure
- Fix for the sync part of commit 823fdb19d7, somehow it didn't pick up the change from the upstream commit b22efbb8b8
Implement volume level changing for Aux/MidiOut/WaveOut devices. It's represented the following WINMM functions:
- auxGetVolume,
- auxSetVolume,
- midiOutGetVolume,
- midiOutSetVolume,
- waveOutGetVolume,
- waveOutSetVolume,
which are calling the followind messages appropriately:
- AUXDM_GETVOLUME,
- AUXDM_SETVOLUME,
- MODM_GETVOLUME,
- MODM_SETVOLUME,
- WODM_GETVOLUME,
- WODM_SETVOLUME.
This fixes volume control for several 3rd-party programs (like Fox Audio Player 0.10.2 from Rapps, Winamp 2.95 with WaveOut plugin). However it does not fix changing the volume in system volume mixers (SndVol32, MMSys), since they are using their own functionality instead. They technically do the same things, but apart from the functions mentioned above.
CORE-14780
Implement GetWavePosition API for both Legacy and MMixer modes.
[WDMAUD.DRV]
- Fix wrong I/O control code passed to DeviceIoControl for Legacy mode. Use IOCTL_GETPOS instead of IOCTL_OPEN_WDMAUD, to use the correct routine.
- Implement WdmAudGetWavePosition for MMixer mode, as it was completely unimplemented there. Call an appropiate MMixer routine and return back resulting wave position.
[WDMAUD]
- Implement WdmAudGetPostion routine, which is used by Legacy mode, and call the same MMixer routine from it too.
- Handle it in IOCTL_GETPOS I/O control request of dispatch routine.
[MMIXER]
- Implement MMixerGetWavePosition internal routine, which is called by both Legacy and MMixer modes, and does the actual work of retrieving playback position.
- Call an apporpriate KSPROPERTY_AUDIO_POSITION property from it, and return in the output resulting KSAUDIO_POSITION.PlayOffset member, which contains the current playback position offset, to be returned to the caller.
This fixes a failure retreiving the current audio playback position snd subsequent playing the audio data by several 3rd-party applications which are using this API (for example, some Gecko based browsers by @roytam1: Basilisk (Serpent) 52.9.0 IA-32 build, NewMoon 28.10.7 IA-32 build and KMeleon 76.5.3 Goanna engine).
CORE-19542
Fix playing wave header multiple times in case the caller requests to do it.
In Windows, it is supported by WHDR_BEGINLOOP and WHDR_ENDLOOP flags (specified together) and dwLoops member of WAVEHDR structure (ususally set to 0xFFFFFFFF (INFINITE constant)).
- Check whenther WHDR_BEGINLOOP | WHDR_ENDLOOP flags are set by the caller.
- If they are, get the amount of times to play the header from WAVEHDR.dwLoops.
- Perform wave header competion only when the loop count is equal to zero. Otherwise, don't do it.
- When the header is entirely committed, in case completion is not needed, reset committed bytes count to the starting value to allow the header play again.
- Decrement loop count in case it isn't set to INFINITE, to mark loop as played correctly. When this count becomes zero, then the playback is finished.
- Get rid from SOUND_OVERLAPPED.PerformCompletion member. Use SOUND_DEVICE_INSTANCE.LoopsRemaining == 0 condition instead.
- Do this only for WaveOut devices, since MSDN states it works only with output buffers. Hence, there is nothing changed for WaveIn.
- Update an appropriate statement about unimplemented functionality from mmebuddy notes.
TODO: handle the case when multiple headers are requested to be looped (WHDR_BEGINLOOP and WHDR_ENDLOOP are set separatedly: 1st flag - in the 1st header, and 2nd in the last header). Currently, only looping a single wave header is supported.
This fixes the playback in the apps those request looped wave playback of some audio data (e. g., BRD Demo app, which did play its sound only first 500 ms before, now it plays endlessly until closing it manually).
CORE-10118
Calculate size of the additinal data based on the format tag specified by the caller.
For PCM wave format, it should be zero, and for all others,
it should be taken from cbSize member of WAVEFORMATEX structure.
- Initialize data size for each format appropriately.
- Append it to the total pin connect allocation size, to allocate enough memory for it.
- Use it as additional data size for requested wave format.
- Append it to the total size of data format.
- Add SAL2 annotations for MMixerInitializeDataFormat function.
Fixes two crashes in winmm:capture and winmm:wave winetests, which have been introduced by 12b3272d9e.
So this is an addendum to that commit.
CORE-19514
[MMIXER] Implement hadling WAVE_FORMAT_EXTENSIBLE audio format
Fix opening audio device error when trying to open it with WAVE_FORMAT_EXTENSIBLE format tag set in wFormatTag member of WAVEFORMATEX:
- Pass additional data size from WAVEFORMATEX.cbSize to pin data format.
- Append it to the whole size of pin data format (KSDATAFORMAT.FormatSize).
- Set additional fields in WAVEFORMATEXTENSIBLE structure (data format, BPS and channel mask) when WAVE_FORMAT_EXTENSIBLE is used. They are used by our inbuilt Intel AC97 miniport driver at least. It simply fails when these members are not set.
- Fix pin connect allocation size by appending an additional data size from WAVEFORMATEX.cbSize to KSPIN_CONNECT + KSDATAFORMAT + WAVEFORMATEX. This allows to proerly initialize additional extensible data and avoids kernel memory leakage when using extensible audio format.
- Remove format tag check which allowed WAVE_FORMAT_PCM to be opened correctly. So now all possible audio formats can be opened properly at least (although it does not mean they may work correctly).
This fixes the audio playback for all apps those are supporting extensible audio data and use it by default (e. g. AIMP 5.30, QMMP 0.12.17, all Chrome/Chromium-based browsers, GameDev Tycoon Demo game etc.).
CORE-10907, CORE-14783
* [KS] Allow passing additional extensible audio data when extensible audio format is used
- Append additional data size from WAVEFORMATEX.cbSize to pin connect size passed to KsCreatePin. If the tag is WAVE_FORMAT_PCM, then this member should always be zero. So in that case, no any additional data is passed to creation request, and the passed data size is correct for PCM too (KSDATAFORMAT + WAVEFORMATEX).
This fixes audio playback in several apps those are supporting extensibble audio and use it by default (e. g. AIMP 5.30, QMMP 0.12.17, all Chrome/Chromium based browsers, GameDev Tycoon Demo game etc.).
CORE-10907, CORE-14783.
* [WDMAUD.DRV] Pass the correct additional data size to I/O control request
Store a correct size of additional data in WAVEFORMATEX.cbSize when performing open of audio device, when WAVE_FORMAT_EXTENSIBLE audio format is used.
It allows to properly open audio device with Legacy APIs enabled too.
This fixes audio playback in several apps those are using extensible audio data (e. g. AIMP 5.30, QMMP 0.12.17, all Chrome/Chromium based browsers, GameDevTycoon Demo game etc.).
CORE-10907, CORE-14783
* [SDK][VIRTIO][NETKVM] Make VirtIO a separate library
This is to avoid code duplication when more VirtIO drivers are brought in. This will also be used on development of a VirtIO XDDM GPU Driver.
* [VIRTIO] Sync with upstream
bdasup: Addendum to 40c15ec (r46632).
kmixer: Addendum to 3e489bf (r42143).
mmixer: Addendum to c42d9f2 (r44872).
stream: Addendum to 4a0debf (r41662).
Serge plans a follow up that will remove all other remaining YDEBUG in the source tree.
The ones covered here he considered to be the most trivial ones.
Instead of adding the rtl_vista library to the target, manually add
the related source files to compilation. That's not the best, but
this should definitively fix the linking problem.
The reason is that both RtlUTF8ToUnicodeN() and RtlUnicodeToUTF8N() are
exported in both kernel and user-mode (ntdll) in Windows 7+.
Conversion from and to UTF8 are fundamental enough that they indeed
deserve to be in a separate file.
Spinlocks are not reentrant (and this is done a lot), using them forces us to have
an horrible hack in the kernel, which unschedules threads which are at DISPATCH_LEVEL
thus allowing another thread to take ownership of the spinlock while the unscheduled
thread should already hold it.
CORE-6473
NEVER DO THIS! It is guaranteed to be wrong. Instead always individually pack single structures that need packing.
This fixes USB mouse on 64 bit builds.
Addendum to 0.4.15-dev-1453-g 4ad7b6d
Looks like CMake on master does not longer understand the syntax of
replace_compile_flags().
Will investigate that later again, when other issues have been
solved that do currently prevent me from testing that locally at all.
Most likely remove_target_compile_option() has to be used instead now.
Not all files are included, but these are necessary to compile cdrom driver.
So far it can only be statically linked with drivers, a proper
implementation requires wdfldr helper driver
