Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dsound: don't restrict the host buffer to 16-bit #774

Merged
merged 1 commit into from
Dec 22, 2023

Commits on Feb 25, 2023

  1. dsound: don't restrict the host buffer to 16-bit

    Currently, the DirectSound Host API code only creates 16-bit integer
    DirectSound buffers. All audio data provided by the user is therefore
    converted by PortAudio to and from 16-bit, regardless of the user buffer
    format.
    
    This basically makes it impossible to pass 24-bit audio through the
    DirectSound Host API.
    
    If the user buffer format is not 16-bit, this also causes pointless
    conversions to take place, *even if the hardware is running at 16-bit*,
    because modern Windows versions (Vista+) convert the data to floating
    point behind the scenes before it is handed off to the hardware. This
    can lead to silly situations where 32-bit float samples from the user
    are (lossily) converted to 16-bit by PortAudio, then ended off to
    Windows via DirectSound, only to be converted back to 32-bit float
    again, before finally being converted to the format the hardware device
    is configured to use. This can easily lead to two layers of
    16-bit dithering (one from PortAudio, and one from Windows) being piled
    on top of each other, resulting in an elevated noise floor.
    
    This commit fixes this problem by configuring the DirectSound buffers to
    use the same format as the user buffer. This should stop PortAudio from
    converting samples in all cases except paInt8, which is not supported by
    WAVEFORMATEX (only paUInt8 is).
    
    The new code assumes that DirectSound will accept whatever format we
    throw at it. I feel confident that this is always true on Vista+
    regardless of hardware, because starting from Vista DirectSound does not
    access hardware directly - it always goes through the Windows Audio
    Engine which supports all formats in both directions (I verified this
    using paloopback).
    
    The consequences of this change on pre-Vista Windows are less clear,
    although [1] suggests that this might just work even on 2000/XP as
    KMixer should be able to handle these conversions as well.
    
    [1]: https://microsoft.public.win32.programmer.directx.audio.narkive.com/elgNlPIn/
    
    Fixes PortAudio#54
    dechamps committed Feb 25, 2023
    Configuration menu
    Copy the full SHA
    00fd54a View commit details
    Browse the repository at this point in the history