I'm making this post so that a) potentially the buffer limit could be increased in a future official build of OBS, and b) so that anyone with sync offset or audio buffer length issues may be able to better understand their issues and possible find a solution that works for them (albeit with recompiling OBS).
TLDR: Audio sync offsets greater (less) than about (-960)ms will cause the audio source to be removed from the output, and this seems to be a hardcoded artificial limit of OBS that is unnecessary, or at least could be implemented better. This might not technically be a bug since it seems to be intentionally programmed this way, but from the a user's perspective it acts like a bug.
I recently began experimenting using the Mixer (Advanced Audio Properties) to sync my microphone input to the desktop audio, in anticipation of using external software to process the microphone audio. I noticed that when set to values in the range of approximately (-900) to (-1000) ms, the audio from the microphone began to cut itself off: It's as if OBS's internal buffer is limited to a single second of audio buffering or something.
I started to dig into the issue, and realized from the log files that this was indeed the case: OBS has a limitation that it can only sync audio within the range of 960ms. From the log file:
total audio buffering is now 960 milliseconds
This didn't really make much sense to me, so I decided to take a look at the source and figure out why this limitation is present. Its presence is clear: There is a definition of MAX_BUFFERING_TICKS=45 in the source code, and this is used to calculate (45*1024*1000/48000) = 960ms. Thing is, this define value only seems to be used to create the buffer limitation, and there does not seem to be any other reason for the limited buffer. No query to see if a buffer space is full, or if a buffer could be expanded, just "You want more than 960ms of buffer? Nope."
So I did the obvious thing and increased the limit in the source code and recompiled OBS. And from what I can tell, there does not seem to be any negative consequences or issues present from increasing this audio buffer limit.
I have made two short 1-minute videos showing the issue and the result of compiling with a value of 450 instead of 45 for the MAX_BUFFERING_TICKS. I change the audio sync offset in the mixer panel, and clearly state the current value in the microphone audio. In the first video a value of (-960)ms begins to produce cut-offs in the microphone audio, but in the second video I can increase the buffer to over (-4000)ms without issue.
Video Showing Issue: https://youtu.be/2NE3-uDlAFI
Video Showing Resolution: https://youtu.be/bMZ8Md8uvy0
Here's the corresponding text from the log file showing the increased audio buffer limit, taken from the recording that produced the second video:
total audio buffering is now 4010 milliseconds
I can understand the potential reason for wanting SOME sort of limit on the buffer, so that it cannot increase exponentially in a worst-case-scenario where for some reason it keeps getting further out-of-sync or someone tries to enter in 2^32 as their offset value. But I have a couple of points to put forward for why I think the current limit needs to be adjusted. First, in my case I simply needed a greater buffer that is not able to be configured in the official builds of OBS. Second, there is no limit to the value that can be entered in the audio mixer panel, even though values greater than a certain range will do nothing. Third, there is no indication that values outside of a certain range will actually cause the audio source to be effectively removed entirely from the output (it took me longer than I'd care to admit to realize that OBS was the problem here). Fourth, this limit appears to be artificial, and hence any hardcoded limit is probably unnecessary. I'll grant that I could have just not discovered any issues created by increasing the audio buffer sync offset limit, but from my perspective it "just worked".
I'll probably continue to use this compiled version of OBS with an increased limit, so I can actually get my very-delayed microphone back in sync with the desktop audio capture. (Saving these offsets in profiles is another matter that I am interested in looking further into.) But it would be nice if, at the very least, the limit could be increased in an official OBS build (ideally not hardcoded?), and it would be very nice if the limit was made prominent in the audio mixer panel somehow.
I'll end with this note from the Dec 20 2015 edit to the OBS source code, which seems to also point to the idea that the audio buffer should be able to handle itself dynamically without this limitation:
The secondary issue that needed fixing was audio buffering. Previously, audio buffering was always a fixed buffer size, so it would always have exactly a certain number of milliseconds of audio buffering (and thus output delay). Instead, it now dynamically increases audio buffering only as necessary, minimizing output delay, and removing the need for users to have to worry about an audio buffering setting.
And this note from Feb 21 2016 which actually nearly halves the maximum audio buffer space for seemingly no technical reason (from 80 to 45).
libobs: Lower max audio tick count to 45 (approx >1 sec)
The default buffering time for audio was always 1 second before the audio subsystem was changed, and it was always more than sufficient for max audio buffering time
TLDR: Audio sync offsets greater (less) than about (-960)ms will cause the audio source to be removed from the output, and this seems to be a hardcoded artificial limit of OBS that is unnecessary, or at least could be implemented better. This might not technically be a bug since it seems to be intentionally programmed this way, but from the a user's perspective it acts like a bug.
I recently began experimenting using the Mixer (Advanced Audio Properties) to sync my microphone input to the desktop audio, in anticipation of using external software to process the microphone audio. I noticed that when set to values in the range of approximately (-900) to (-1000) ms, the audio from the microphone began to cut itself off: It's as if OBS's internal buffer is limited to a single second of audio buffering or something.
I started to dig into the issue, and realized from the log files that this was indeed the case: OBS has a limitation that it can only sync audio within the range of 960ms. From the log file:
total audio buffering is now 960 milliseconds
This didn't really make much sense to me, so I decided to take a look at the source and figure out why this limitation is present. Its presence is clear: There is a definition of MAX_BUFFERING_TICKS=45 in the source code, and this is used to calculate (45*1024*1000/48000) = 960ms. Thing is, this define value only seems to be used to create the buffer limitation, and there does not seem to be any other reason for the limited buffer. No query to see if a buffer space is full, or if a buffer could be expanded, just "You want more than 960ms of buffer? Nope."
So I did the obvious thing and increased the limit in the source code and recompiled OBS. And from what I can tell, there does not seem to be any negative consequences or issues present from increasing this audio buffer limit.
I have made two short 1-minute videos showing the issue and the result of compiling with a value of 450 instead of 45 for the MAX_BUFFERING_TICKS. I change the audio sync offset in the mixer panel, and clearly state the current value in the microphone audio. In the first video a value of (-960)ms begins to produce cut-offs in the microphone audio, but in the second video I can increase the buffer to over (-4000)ms without issue.
Video Showing Issue: https://youtu.be/2NE3-uDlAFI
Video Showing Resolution: https://youtu.be/bMZ8Md8uvy0
Here's the corresponding text from the log file showing the increased audio buffer limit, taken from the recording that produced the second video:
total audio buffering is now 4010 milliseconds
I can understand the potential reason for wanting SOME sort of limit on the buffer, so that it cannot increase exponentially in a worst-case-scenario where for some reason it keeps getting further out-of-sync or someone tries to enter in 2^32 as their offset value. But I have a couple of points to put forward for why I think the current limit needs to be adjusted. First, in my case I simply needed a greater buffer that is not able to be configured in the official builds of OBS. Second, there is no limit to the value that can be entered in the audio mixer panel, even though values greater than a certain range will do nothing. Third, there is no indication that values outside of a certain range will actually cause the audio source to be effectively removed entirely from the output (it took me longer than I'd care to admit to realize that OBS was the problem here). Fourth, this limit appears to be artificial, and hence any hardcoded limit is probably unnecessary. I'll grant that I could have just not discovered any issues created by increasing the audio buffer sync offset limit, but from my perspective it "just worked".
I'll probably continue to use this compiled version of OBS with an increased limit, so I can actually get my very-delayed microphone back in sync with the desktop audio capture. (Saving these offsets in profiles is another matter that I am interested in looking further into.) But it would be nice if, at the very least, the limit could be increased in an official OBS build (ideally not hardcoded?), and it would be very nice if the limit was made prominent in the audio mixer panel somehow.
I'll end with this note from the Dec 20 2015 edit to the OBS source code, which seems to also point to the idea that the audio buffer should be able to handle itself dynamically without this limitation:
The secondary issue that needed fixing was audio buffering. Previously, audio buffering was always a fixed buffer size, so it would always have exactly a certain number of milliseconds of audio buffering (and thus output delay). Instead, it now dynamically increases audio buffering only as necessary, minimizing output delay, and removing the need for users to have to worry about an audio buffering setting.
And this note from Feb 21 2016 which actually nearly halves the maximum audio buffer space for seemingly no technical reason (from 80 to 45).
libobs: Lower max audio tick count to 45 (approx >1 sec)
The default buffering time for audio was always 1 second before the audio subsystem was changed, and it was always more than sufficient for max audio buffering time