sdk/lib/drivers · reactos · Tangled

huwcampbell.com / reactos

Reactos

reactos sdk lib drivers

14 folders · 1 file

Oleg Dubinskiy · [MMIXER] Further imrovements to volume control support (follow-up of 376708b) 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 · 8mo ago

[SDK:DDK][NTOS:PNP] Implement PnP arbiters initialization

[FORMATTING][NTOS][HAL][DRIVERS][SDK] Fix trailing spaces

[REACTOS] Fix 'writting' typos (#7484)

[FORMATTING][NTOS][HAL][DRIVERS][SDK] Fix trailing spaces

[FORMATTING][NTOS][HAL][DRIVERS][SDK] Fix trailing spaces

[SDK][WDF][USBDEX][NTOSKRNL_VISTA] Fully enable KMDF (#8396)

[REACTOS] Refresh old URLs (#7632)

[NTOS] Remove ROS-specific __NTOSKRNL__

[REACTOS] Explicitly link against pseh & include pseh headers in a few places

[MMIXER] Further imrovements to volume control support (follow-up of 376708b) 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

[SPTILIB] Introduce SPTI static library for storage drivers (#8209)

[SDK][WDF][USBDEX][NTOSKRNL_VISTA] Fully enable KMDF (#8396)

[REACTOS] Add missing line breaks at end of file

[WDF] HACK: Workaround PCI causing DPCs to be flushed when system affinity is disabled

[SDK][WDF][USBDEX][NTOSKRNL_VISTA] Fully enable KMDF (#8396)