Operating System Info
Windows 11
Other OS
No response
OBS Studio Version
32.2.2
OBS Studio Version (Other)
No response
OBS Studio Log URL
https://obsproject.com/logs/CICmxeCpMAmlvztN
OBS Studio Crash Log URL
No response
Expected Behavior
The expected behavior for all pro DAWs is to use 48KHz or higher to up sample, and when the default are 44.1KHz, it causes a trainwreck because almost everything else use 48Khz now; so all devices are now expected to run at 48Khz and when they don't they can take down the USB bus when max audio buffering. When OBS is configured for 48 kHz and the HDMI capture-card audio endpoint is also configured for 48 kHz in Windows, the DirectShow audio stream associated with the Video Capture Device should initialize at 48 kHz.
The capture-card audio should remain synchronized and continuous without rapidly accumulating audio buffering, restarting, crackling, or becoming distorted.
Current Behavior
OBS must run at 48Khz internal because we are recording audio devices that run at 44.1Khz so we require 48Khz default so the synchronized clocks don't destroy the audio and add artifacts. OBS initializes the HDMI capture card’s separate DirectShow audio filter at 44.1 kHz even though:
- OBS is configured for 48 kHz.
- The capture card’s Windows audio endpoint is configured for 48 kHz.
- The other active audio endpoints are configured for 48 kHz.
Example from the OBS log:
text
audio settings reset:
samples per sec: 48000
speakers: 2
Later, when the HDMI capture source initializes:
text
[DShow Device: 'L.Video.In'] settings updated:
video device: Live Streamer CAP 4K
resolution: 3840x2160
fps: 29.97
format: NV12
buffering: disabled
hardware decode: disabled
using video device audio: no
separate audio filter
sample rate: 44100
channels: 2
audio type: Capture
Almost immediately, OBS reaches its maximum audio buffer:
text
Max audio buffering reached!
adding 960 milliseconds of audio buffering, total audio buffering is now 960 milliseconds (source: L.Video.In)
Source L.Video.In audio is lagging (over by 211.59 ms) at max audio buffering. Restarting source audio.
The resulting audio is severely glitched, delayed, and/or repeatedly restarted.
Changing the Windows endpoint format to 48 kHz does not appear to affect the format negotiated by the DirectShow audio filter. It appears that the Windows audio-endpoint format and the DirectShow audio-pin format are negotiated independently.
Steps to Reproduce
-
Connect an HDMI USB capture card with an audio interface. The device used in this example is an AVerMedia Live Streamer CAP 4K.
-
In Windows Sound settings, configure the capture card’s HDMI audio endpoint for 48 kHz.
-
In OBS, open Settings → Audio and select 48 kHz as the sample rate.
-
Add or configure a Video Capture Device source using the capture card.
-
Configure the source as follows:
- Resolution: 3840x2160
- Frame rate: 29.97
- Video format: NV12
- Buffering: Disabled
- Use the capture card’s separate/custom audio device
-
Start OBS or reload the scene collection.
-
Open the OBS log.
-
Observe that OBS reports:
text
sample rate: 44100
for the DirectShow source even though OBS and the Windows endpoint are configured for 48 kHz.
-
Within a short period, observe:
text
Max audio buffering reached!
followed by:
text
Source L.Video.In audio is lagging ... Restarting source audio.
Anything else we should know?
This issue is system because decades ago computers were slow so we used 44.1KHz and people didn't hook up media devices to their sound card so we didn't need 48KHz, but today that has changed, and all DAWs use 48Khz because media players output 44.1Khz and if we don't up sample to 48KHz because if we don't the synced clocks will destroy the audio quality.
This attached log is from after I got the system working by setting all the video inputs to "use_custom_audio_device": true, "audio_device_id": "", it's the only way to disable the audio device and I have to edit the scene set by hand, I'm a compute engineer, I spend days with Hermes Agent and ChatGPT diagnosing this problem and I have verified this is OBS bug, not my system; I have removed all things that could cause a problem. My scene set is very large, so the problems compounded until the system was not usable. Every time I change the settings back in Windows to 48KHz, Windows comes through and changes some of them back. I had ChatGPT write a script to automatically set all the Windows Audio Devices to force 48KHz and that really helped, but when OBS loads the HDMI capture card, which disabled 48KHz in Windows Sound settings, loads the HDMI capture card at 44.1KHz, you're destroyed my ability to fix the problem. Users editing the scene json file is not acceptable fix, we have to be able to disable the HDMI audio entirely, but the option is not available enough the DirectShow supports it.
Environment:
text
OBS Studio: 32.2.2, 64-bit
Operating system: Windows 11 25H2
Windows build: 26200.9168
Capture device: AVerMedia Live Streamer CAP 4K
Video mode: 3840x2160 at 29.97 FPS, NV12
OBS sample rate: 48000 Hz
Windows capture-endpoint format: 48000 Hz
DirectShow audio-filter format reported by OBS: 44100 Hz
OBS maximum audio buffering: 960 ms
The Windows capture endpoint appears as:
text
HDMI (Live Streamer CAP 4K)
The relevant OBS source is:
text
L.Video.In
This does not appear to be ordinary CPU or encoder overload. In the affected recording, rendering and encoding lag were both approximately 0.5%, while the DirectShow audio source independently reached 960 ms of buffering and restarted.
The USB configuration was also reduced during testing. Replacing another capture device with the known-good Live Streamer CAP 4K and removing the external MOTU audio interface stopped the USB controller crashes and keyboard/mouse outages, but the DirectShow audio problem remained. This made the 44.1 kHz negotiation and subsequent buffering independently reproducible without the external audio interface.
The OBS scene data for the affected source contains:
json
{
"name": "L.Video.In",
"id": "dshow_input",
"settings": {
"last_resolution": "3840x2160",
"resolution": "3840x2160",
"use_custom_audio_device": true,
"buffering": 2,
"audio_device_id": "",
"video_device_id": "Live Streamer CAP 4K:...",
"frame_interval": -1,
"res_type": 1,
"video_format": 201,
"active": true,
"color_space": "709",
"color_range": "partial",
"hw_decode": false
}
}
A useful improvement would be one or more of the following:
- Allow the DirectShow audio format to be selected explicitly.
- Prefer the OBS project sample rate when the device supports it.
- Expose the negotiated DirectShow audio format in the source properties.
- Warn when the DirectShow audio pin initializes at a different rate from the OBS project.
- Resample or recover without allowing the source to immediately reach 960 ms of buffering and repeatedly restart.
- Clarify whether the Windows audio-endpoint format is expected to have no effect on the DirectShow audio filter.
I can provide the complete OBS log and scene-collection source configuration if needed.
Operating System Info
Windows 11
Other OS
No response
OBS Studio Version
32.2.2
OBS Studio Version (Other)
No response
OBS Studio Log URL
https://obsproject.com/logs/CICmxeCpMAmlvztN
OBS Studio Crash Log URL
No response
Expected Behavior
The expected behavior for all pro DAWs is to use 48KHz or higher to up sample, and when the default are 44.1KHz, it causes a trainwreck because almost everything else use 48Khz now; so all devices are now expected to run at 48Khz and when they don't they can take down the USB bus when max audio buffering. When OBS is configured for 48 kHz and the HDMI capture-card audio endpoint is also configured for 48 kHz in Windows, the DirectShow audio stream associated with the Video Capture Device should initialize at 48 kHz.
The capture-card audio should remain synchronized and continuous without rapidly accumulating audio buffering, restarting, crackling, or becoming distorted.
Current Behavior
OBS must run at 48Khz internal because we are recording audio devices that run at 44.1Khz so we require 48Khz default so the synchronized clocks don't destroy the audio and add artifacts. OBS initializes the HDMI capture card’s separate DirectShow audio filter at 44.1 kHz even though:
Example from the OBS log:
text
audio settings reset:
samples per sec: 48000
speakers: 2
Later, when the HDMI capture source initializes:
text
[DShow Device: 'L.Video.In'] settings updated:
video device: Live Streamer CAP 4K
resolution: 3840x2160
fps: 29.97
format: NV12
buffering: disabled
hardware decode: disabled
using video device audio: no
separate audio filter
sample rate: 44100
channels: 2
audio type: Capture
Almost immediately, OBS reaches its maximum audio buffer:
text
Max audio buffering reached!
adding 960 milliseconds of audio buffering, total audio buffering is now 960 milliseconds (source: L.Video.In)
Source L.Video.In audio is lagging (over by 211.59 ms) at max audio buffering. Restarting source audio.
The resulting audio is severely glitched, delayed, and/or repeatedly restarted.
Changing the Windows endpoint format to 48 kHz does not appear to affect the format negotiated by the DirectShow audio filter. It appears that the Windows audio-endpoint format and the DirectShow audio-pin format are negotiated independently.
Steps to Reproduce
Connect an HDMI USB capture card with an audio interface. The device used in this example is an AVerMedia Live Streamer CAP 4K.
In Windows Sound settings, configure the capture card’s HDMI audio endpoint for 48 kHz.
In OBS, open Settings → Audio and select 48 kHz as the sample rate.
Add or configure a Video Capture Device source using the capture card.
Configure the source as follows:
Start OBS or reload the scene collection.
Open the OBS log.
Observe that OBS reports:
text
sample rate: 44100
for the DirectShow source even though OBS and the Windows endpoint are configured for 48 kHz.
Within a short period, observe:
text
Max audio buffering reached!
followed by:
text
Source L.Video.In audio is lagging ... Restarting source audio.
Anything else we should know?
This issue is system because decades ago computers were slow so we used 44.1KHz and people didn't hook up media devices to their sound card so we didn't need 48KHz, but today that has changed, and all DAWs use 48Khz because media players output 44.1Khz and if we don't up sample to 48KHz because if we don't the synced clocks will destroy the audio quality.
This attached log is from after I got the system working by setting all the video inputs to "use_custom_audio_device": true, "audio_device_id": "", it's the only way to disable the audio device and I have to edit the scene set by hand, I'm a compute engineer, I spend days with Hermes Agent and ChatGPT diagnosing this problem and I have verified this is OBS bug, not my system; I have removed all things that could cause a problem. My scene set is very large, so the problems compounded until the system was not usable. Every time I change the settings back in Windows to 48KHz, Windows comes through and changes some of them back. I had ChatGPT write a script to automatically set all the Windows Audio Devices to force 48KHz and that really helped, but when OBS loads the HDMI capture card, which disabled 48KHz in Windows Sound settings, loads the HDMI capture card at 44.1KHz, you're destroyed my ability to fix the problem. Users editing the scene json file is not acceptable fix, we have to be able to disable the HDMI audio entirely, but the option is not available enough the DirectShow supports it.
Environment:
text
OBS Studio: 32.2.2, 64-bit
Operating system: Windows 11 25H2
Windows build: 26200.9168
Capture device: AVerMedia Live Streamer CAP 4K
Video mode: 3840x2160 at 29.97 FPS, NV12
OBS sample rate: 48000 Hz
Windows capture-endpoint format: 48000 Hz
DirectShow audio-filter format reported by OBS: 44100 Hz
OBS maximum audio buffering: 960 ms
The Windows capture endpoint appears as:
text
HDMI (Live Streamer CAP 4K)
The relevant OBS source is:
text
L.Video.In
This does not appear to be ordinary CPU or encoder overload. In the affected recording, rendering and encoding lag were both approximately 0.5%, while the DirectShow audio source independently reached 960 ms of buffering and restarted.
The USB configuration was also reduced during testing. Replacing another capture device with the known-good Live Streamer CAP 4K and removing the external MOTU audio interface stopped the USB controller crashes and keyboard/mouse outages, but the DirectShow audio problem remained. This made the 44.1 kHz negotiation and subsequent buffering independently reproducible without the external audio interface.
The OBS scene data for the affected source contains:
json
{
"name": "L.Video.In",
"id": "dshow_input",
"settings": {
"last_resolution": "3840x2160",
"resolution": "3840x2160",
"use_custom_audio_device": true,
"buffering": 2,
"audio_device_id": "",
"video_device_id": "Live Streamer CAP 4K:...",
"frame_interval": -1,
"res_type": 1,
"video_format": 201,
"active": true,
"color_space": "709",
"color_range": "partial",
"hw_decode": false
}
}
A useful improvement would be one or more of the following:
I can provide the complete OBS log and scene-collection source configuration if needed.