Resource icon
- Thread starter adocilesloth
- Start date
CapoFantasma97
New Member
I was going to scream "IT'S PERFECT", until I checked the test of the recording and I found the beep in it.
adocilesloth
Member
As I suspect this will come up a lot, I shall attempt to address the first 'beep' being recorded.
At the time of writing, as far as I'm aware, there is no way to get if the stream/recording button has been pressed via OBS's API. So the only way (I've found) to do this is to monitor if a stream/recording is active. As a result, the first 'beep' happens just after the stream/recording goes from being inactive (or not happening) to active (happening) so it can only occur once the stream/recording is running and so is recorded. The second beep works similarly but once the stream/recording goes from active to inactive so isn't captured.
If this is a problem, off the top of my head there are two options:
You accept this will happen and embrace it. Change the beep to some bad ass intro music and have it as an intro. From what I've read, some people are lazy when it comes to editing so this may cut out some of this out.
You accept that this will happen and remove the beep. Use a virtual audio cable to channel audio to OBS and have your programs play through that (as well as your desktop obviously) but do not have OBS's audio going through the virtual audio cable. There are guides about for using virtual audio cables, I'm sure.
Maybe one of these will suit you @Unit and @CapoFantasma97
At the time of writing, as far as I'm aware, there is no way to get if the stream/recording button has been pressed via OBS's API. So the only way (I've found) to do this is to monitor if a stream/recording is active. As a result, the first 'beep' happens just after the stream/recording goes from being inactive (or not happening) to active (happening) so it can only occur once the stream/recording is running and so is recorded. The second beep works similarly but once the stream/recording goes from active to inactive so isn't captured.
If this is a problem, off the top of my head there are two options:
You accept this will happen and embrace it. Change the beep to some bad ass intro music and have it as an intro. From what I've read, some people are lazy when it comes to editing so this may cut out some of this out.
You accept that this will happen and remove the beep. Use a virtual audio cable to channel audio to OBS and have your programs play through that (as well as your desktop obviously) but do not have OBS's audio going through the virtual audio cable. There are guides about for using virtual audio cables, I'm sure.
Maybe one of these will suit you @Unit and @CapoFantasma97
SupaFly::.
New Member
If you don't like the sounds the dev included, go here: http://www.soundjay.com/beep-sounds-1.html
Download Beep 7 and Beep 8 as MP3s, open and navigate to folder "..obs-studio\data\obs-plugins\SRBeep" rename your downloaded Beep 7 to record_start_sound.mp3 and Beep 8 to record_stop_sound.mp3 copy and replace them in the OBS Plugin folder with the patch specified above..
For the streaming sounds do the same!
And you're done!
Much better! Lol
As for the dev, could you work on a image overlay, sort of like a "trademark" stamp using this image:
or the traditional ● REC in red when recording is active.
Download Beep 7 and Beep 8 as MP3s, open and navigate to folder "..obs-studio\data\obs-plugins\SRBeep" rename your downloaded Beep 7 to record_start_sound.mp3 and Beep 8 to record_stop_sound.mp3 copy and replace them in the OBS Plugin folder with the patch specified above..
For the streaming sounds do the same!
And you're done!
Much better! Lol
As for the dev, could you work on a image overlay, sort of like a "trademark" stamp using this image:
or the traditional ● REC in red when recording is active.
Vols and Jezuz
New Member
With both OBS Studio 32-bit and 64-bit on Windows 7 x64, SRBeep seems to be working as intended but I get an application crash with EventID 1000 upon every exit. Removing SRBeep DLLs makes the crashes go away. I've tried repairing my VC++ 2013 redistributables. I tried to download the source code and recompile it myself, but couldn't get it working (probably because I'm using Visual Studio 2008). Any idea what is causing the crash? I'll give you the information from Event Viewer from one of the 32-bit crashes in case it can provide any clues.
Faulting application name: obs32.exe, version: 0.0.0.0, time stamp: 0x57a87607
Faulting module name: MSVCR120.dll, version: 12.0.21005.1, time stamp: 0x524f7ce6
Exception code: 0x40000015
Fault offset: 0x000a7676
Faulting process id: 0x67c
Faulting application start time: 0x01d216e9c896f53c
Faulting application path: C:\Program Files (x86)\obs-studio\bin\32bit\obs32.exe
Faulting module path: C:\Windows\system32\MSVCR120.dll
Report Id: 0a0efbbd-82dd-11e6-8280-000f530d0d08
Faulting application name: obs32.exe, version: 0.0.0.0, time stamp: 0x57a87607
Faulting module name: MSVCR120.dll, version: 12.0.21005.1, time stamp: 0x524f7ce6
Exception code: 0x40000015
Fault offset: 0x000a7676
Faulting process id: 0x67c
Faulting application start time: 0x01d216e9c896f53c
Faulting application path: C:\Program Files (x86)\obs-studio\bin\32bit\obs32.exe
Faulting module path: C:\Windows\system32\MSVCR120.dll
Report Id: 0a0efbbd-82dd-11e6-8280-000f530d0d08
Vols and Jezuz
New Member
I looked into the logs and when I have SRBeep installed, these lines always show up:
22:34:04.437: Freeing OBS context data
22:34:04.437: 2 output(s) were remaining
Now the first line I get without SRBeep and I think it's part of the standard log output during shutdown, but the "2 output(s) were remaining" only with SRBeep.
Furthermore, the last line reports the "Number of memory leaks", which is always 1 for me without SRBeep. But with SRBeep, it's 3. So presumably those 2 remaining outputs had to do with pointers or handles in SRBeep not being closed/deallocated properly before the program is exiting. I couldn't find anything obvious to me in the source code that would cause this, so I really don't know where to go from here.
22:34:04.437: Freeing OBS context data
22:34:04.437: 2 output(s) were remaining
Now the first line I get without SRBeep and I think it's part of the standard log output during shutdown, but the "2 output(s) were remaining" only with SRBeep.
Furthermore, the last line reports the "Number of memory leaks", which is always 1 for me without SRBeep. But with SRBeep, it's 3. So presumably those 2 remaining outputs had to do with pointers or handles in SRBeep not being closed/deallocated properly before the program is exiting. I couldn't find anything obvious to me in the source code that would cause this, so I really don't know where to go from here.
Vols and Jezuz
New Member
I installed Visual Studio 2013 so I could compile SRBeep myself. Doing so gave the same crash as with the released DLL.
On a hunch, I changed all the std::thread objects to boost::thread objects, and std::atomic to boost::atomic (and of course changed the includes and linker libraries to the boost directories), and this actually fixed the OBS Studio crash on exit for me. Only downside is that using the boost libraries increased the SRBeep.dll file size from 28KB to 91KB, but it's still tiny anyway.
I don't know if I was the only one having this problem, but on my system at least, it's apparent that the std::thread and/or std::atomic objects were the cause of the crashes.
If anyone else is having this issue and doesn't know how to recompile with the changes I mentioned or doesn't want to go through with the hassle, let me know and I can upload my modified SRBeep.dll file.
On a hunch, I changed all the std::thread objects to boost::thread objects, and std::atomic to boost::atomic (and of course changed the includes and linker libraries to the boost directories), and this actually fixed the OBS Studio crash on exit for me. Only downside is that using the boost libraries increased the SRBeep.dll file size from 28KB to 91KB, but it's still tiny anyway.
I don't know if I was the only one having this problem, but on my system at least, it's apparent that the std::thread and/or std::atomic objects were the cause of the crashes.
If anyone else is having this issue and doesn't know how to recompile with the changes I mentioned or doesn't want to go through with the hassle, let me know and I can upload my modified SRBeep.dll file.
adocilesloth
Member
@Vols and Jezuz
Out of curiosity, does it still crash if you only change std::atomic to boost::atomic and leave std::thread alone? I've had problems with std::atomic before and I'm just wondering if it's a problem with just atomic.
I'm also sort of being a bit "unclean" with how the plugin unloads. It doesn't shutdown the thread that it creates (in Windows) to avoid a crash. This may be causing your crash as well. If you are still curious, you could change
to
and see if that stops the plugin crashing but please don't feel obliged.
Either way, thanks for looking into this, I appreciate it. I'll have to have a look at the boost libs and see if they are worth using over the std thread stuff.
Out of curiosity, does it still crash if you only change std::atomic to boost::atomic and leave std::thread alone? I've had problems with std::atomic before and I'm just wondering if it's a problem with just atomic.
I'm also sort of being a bit "unclean" with how the plugin unloads. It doesn't shutdown the thread that it creates (in Windows) to avoid a crash. This may be causing your crash as well. If you are still curious, you could change
Code:
void obs_module_unload(void)
{
#ifdef _WIN32
return;
#else
closed = true;
if(SRBeepThread.joinable())
{
SRBeepThread.join();
}
return;
#endif
}to
Code:
void obs_module_unload(void)
{
closed = true;
if(SRBeepThread.joinable())
{
SRBeepThread.join();
}
return;
}and see if that stops the plugin crashing but please don't feel obliged.
Either way, thanks for looking into this, I appreciate it. I'll have to have a look at the boost libs and see if they are worth using over the std thread stuff.
Vols and Jezuz
New Member
Just tested switching only std::atomic to boost::atomic and it gets the original crash. Then went and only changed std::thread to boost::thread, leaving std::atomic, and the crash is fixed again. So it is definitely the std::thread objects. Still, with my fix, the log is still noting "2 output(s) were remaining" and 2 extra memory leaks as with the original code, so it would seem like using boost::thread is just 'covering up' or something. So now I am leaving std::atomic but changing std::thread to boost::thread everywhere it appears. Just to confirm in case you want to test for yourself, the only other code change is altering #include <thread> to #include <boost/thread.hpp>. Then it's as simple as adding the boost root dir to "Additional Include Libraries" and stage\lib in the boost root dir to "Additional Library Directories. Boost was built using the included bootstrap batch file as per the documentation.
Funny enough, that changed you proposed was the first thing I tried before changing to boost, and it gives a different, worse crash. It's different because the crash notification appears to be from OBS Studio itself and not the bog standard Windows crash message box. And worse because even though the Window closes, the OBS Studio process keeps running in the background until ended through Task Manager.
I must apologize now because I am fairly new to Windows API, C++, and coding in general, so I really don't know much and may be wrong about any number of things. But as you probably know, boost is basically intended to bring older C++ standards up to date, or at least more up to date, with C++11 and future standards.
So in theory boost::thread and std::thread would be the same, but I know many of the boost libraries and in particular boost::thread have some minor differences with the std libraries. I don't know what they are in particular, but my guess would be that, as coded and with my modifications, they are both either leaving open thread handles on module unload or the reference count is getting messed up when the code is exited with the threads left in a joinable state. Hence why OBS Studio log reports "2 output(s) were remaining" and 2 extra memory leaks either way. So either boost::thread must have some way of detecting the potentially fatal error and has some workaround to avoid it, or std::thread is purposefully causing a crash when it detects the memory leaks as some kind of ham-handed debugging. Hope this helps somehow
Funny enough, that changed you proposed was the first thing I tried before changing to boost, and it gives a different, worse crash. It's different because the crash notification appears to be from OBS Studio itself and not the bog standard Windows crash message box. And worse because even though the Window closes, the OBS Studio process keeps running in the background until ended through Task Manager.
I must apologize now because I am fairly new to Windows API, C++, and coding in general, so I really don't know much and may be wrong about any number of things. But as you probably know, boost is basically intended to bring older C++ standards up to date, or at least more up to date, with C++11 and future standards.
So in theory boost::thread and std::thread would be the same, but I know many of the boost libraries and in particular boost::thread have some minor differences with the std libraries. I don't know what they are in particular, but my guess would be that, as coded and with my modifications, they are both either leaving open thread handles on module unload or the reference count is getting messed up when the code is exited with the threads left in a joinable state. Hence why OBS Studio log reports "2 output(s) were remaining" and 2 extra memory leaks either way. So either boost::thread must have some way of detecting the potentially fatal error and has some workaround to avoid it, or std::thread is purposefully causing a crash when it detects the memory leaks as some kind of ham-handed debugging. Hope this helps somehow
Last edited:
Vols and Jezuz
New Member
I just tried a different way of going about the change you mentioned still using std::thread, but doing SRBeepThread.detach() instead of SRBeepThread.join() in an effort to tidy up and make the SRBeep thread not joinable on module unload. It behaves the exact same as the original code, crashing with the bog standard Windows message box and not leaving the OBS Studio process running in the background. Strange
adocilesloth
Member
Thanks for messing with the atomics and threads. Don't apologise for being new to stuff, all I've been doing is throwing mud at a wall and seeing what sticks. One day I'll learn how to make plugins without memory leaks and/or find memory leaks. Until then, I'll take 2 over the 30+ that I have in another project...
Anyway, thanks for messing with the tread stuff. Hopefully it'll help me track down the bugs :)
Anyway, thanks for messing with the tread stuff. Hopefully it'll help me track down the bugs :)
Vols and Jezuz
New Member
How coincidental, throwing mud at a wall and seeing what sticks is my official programming method as well!
I'm guessing that OBS Studio crashing from the .join() function is as confusing to you as it is to me. Maybe OBS Studio tries to proceed with closing without waiting on SRBeepThread to join despite the .join() function call, thus giving undefined behavior in the std::thread logic and leading to that different crash where the OBS Studio process is still running in the background, because the undefined behavior leaves SRBeepThread in some kind of indefinite hung execution state.
I'm thinking that the code can maybe be reworked in such a way as to avoid threading altogether, so I will try that later and see if that can avoid the memory leaks while providing the same functionality.
I'm guessing that OBS Studio crashing from the .join() function is as confusing to you as it is to me. Maybe OBS Studio tries to proceed with closing without waiting on SRBeepThread to join despite the .join() function call, thus giving undefined behavior in the std::thread logic and leading to that different crash where the OBS Studio process is still running in the background, because the undefined behavior leaves SRBeepThread in some kind of indefinite hung execution state.
I'm thinking that the code can maybe be reworked in such a way as to avoid threading altogether, so I will try that later and see if that can avoid the memory leaks while providing the same functionality.
Vols and Jezuz
New Member
Well I have no idea if this fixed the memory leak, or if there was one, but this at least doesn't give crash on exit for me using std::thread.
https://gist.github.com/VolsandJezuz/a27ec7dee2c0d7e5fb869212780d984f
https://gist.github.com/VolsandJezuz/a27ec7dee2c0d7e5fb869212780d984f
Last edited:
Vols and Jezuz
New Member
https://gist.github.com/VolsandJezuz/a27ec7dee2c0d7e5fb869212780d984f/revisions?diff=split
With these changes, I was able to get SRBeep to properly play start/stop sounds reliably no matter how short the interval in between starting and stopping. This is useful if you use hotkeys, because sometimes I'm recording a game and want to quickly stop/restart with hotkeys to split the recording. Without these newest changes, SRBeep would miss playing a start or sound if I stopped/restarted the recording with hotkeys too quickly, because the second thread's call to open the SDL audio device failed with corresponding log entry due to the device not yet being freed by the first thread.
The sleep interval was moved to the end of main_loop's while, so the continue statements allow SRBeep to immediately recheck the recording/streaming status. The audioMutex buffers the sound playback by blocking the main_loop from calling play_clip with another thread until the SDL audio device is free from the first sound.
With these changes, I was able to get SRBeep to properly play start/stop sounds reliably no matter how short the interval in between starting and stopping. This is useful if you use hotkeys, because sometimes I'm recording a game and want to quickly stop/restart with hotkeys to split the recording. Without these newest changes, SRBeep would miss playing a start or sound if I stopped/restarted the recording with hotkeys too quickly, because the second thread's call to open the SDL audio device failed with corresponding log entry due to the device not yet being freed by the first thread.
The sleep interval was moved to the end of main_loop's while, so the continue statements allow SRBeep to immediately recheck the recording/streaming status. The audioMutex buffers the sound playback by blocking the main_loop from calling play_clip with another thread until the SDL audio device is free from the first sound.
Vols and Jezuz
New Member
I had changed the formatting/style a little to what I used to, and I realized that might be kind of annoying if you wanted to use my code for a commit, so I updated it to match the original formatting/style when possible and made the added/changed code like the original as well.
https://gist.github.com/VolsandJezuz/a27ec7dee2c0d7e5fb869212780d984f
https://gist.github.com/VolsandJezuz/a27ec7dee2c0d7e5fb869212780d984f
adocilesloth
Member
Dam, your mud is better than my mud.
If your happy to do it, please make a pull request on the git repo so I can merge it over. I kinda wanna steal all of your code...
Vols and Jezuz
New Member
What do you mean by mud? I'm not hip with all the cool programming lingo obviously lol
You're more than welcome to what I did. My changes were largely based off what Automatic Scene Switcher was doing, so I don't know if you want to add some credit to them somehow.
Edit: alright I think I did the forking and pull request correctly. If not, let me know. Some of the spacing was a little different, idk if it matters to you.
You're more than welcome to what I did. My changes were largely based off what Automatic Scene Switcher was doing, so I don't know if you want to add some credit to them somehow.
Edit: alright I think I did the forking and pull request correctly. If not, let me know. Some of the spacing was a little different, idk if it matters to you.
Last edited:
adocilesloth
Member
I was on about:
Thanks I've merged it across :) When I get some time (hopefully today or at the weekend) I'll update the plugin.