Performance tips? Here's one: switching recorders to 48k sample-rate will significantly improve performance #685
Replies: 3 comments 6 replies
-
|
The analysis is done on a 48kHz mono signal, so avoiding to record multi-channel audio will also speed up processing time. |
Beta Was this translation helpful? Give feedback.
-
|
It took me a while to get back to this. I liked your idea of switching to mono files and wanted to see if it would be worth converting my files to mono before running them (I need stereo for other analyses). I made a mono version of one of my (1 hour) files and then made a gaggle of copies of each and ran them. For me, the difference is pretty small and I'm gonna just keep running them in stereo. YMMV here are the results of the run: Mono 10.wav 48.33 seconds Stereo 10.wav 49.42 seconds |
Beta Was this translation helpful? Give feedback.
-
|
If you need multi-channel audio for other analyses, you should stick to it and there is no real benefit in converting it to mono in before. I've been playing around with a different audio backend (in the following named as "new") and also did several tests for comparison with the current audio backend (in the following named as "old") during the past weeks. A simple test with a 1s 48kHz wave file opened (and converted to mono) 100 times at constant CPU speed got the following results for different number of channels: 1c Of course, my test does the best to remove effects of I/O, so the time measured just reflects the required time for decoding and converting everything in memory. With the current audio backend stereo takes 5 times the time of mono and increasing the number of channels only leads to a small increase in runtime, so 6 channels takes 8 times the time of mono. With the new audio backend stereo takes almost as long as two times mono and increasing the number of channels roughly adds the time of one mono channel per new channel, so 6 channels takes even more than 6 times the time of mono. You might argue now, that testing with a one second file isn't telling anything, so I made the same test again and changed the file duration to 600s: 1c With the old audio backend we get a factor of about 30 for mono and about 50 for multi-channel, so stereo takes almost 9 times the time of mono and 6 channels takes more than 14 times the time of mono. With the new backend the factor is about 10 for mono and stereo and dropping to about 5 to 6 for more channels, so the effect of more channels is decreasing with longer audio files, but 6 channels still takes almost 4 times the time of mono. After all, I think I have been able to show that there is quite an effect in providing mono audio files compared to multi-channel audio files. The reason, why I'm referring to the current backend as old, is just that I dropped it in favor of the new backend in the part of the BirdNET infrastructure which is under my control. So be warned, that this might happen to the BirdNET Analyzer, too (just because there is support for much more file formats and audio codecs). |
Beta Was this translation helpful? Give feedback.
-
|
Interesting! I've got lots of questions. The first series of results seems to show that the Old method is a LOT faster than the New one, especially as channel-count goes up. By the end (7 channels), Old is processing in .429 seconds while New is taking a whopping 10.5 seconds. you want to take a look at those numbers? if they're true, the New backend looks like it will be really slow compared to the old one. the second series of numbers seems similar, and again New appears to be much slower than Old -- in that sequence a 1 channel processed with Old takes 1.48 seconds while running New takes 13.502! Yikes! If that New process is headed for BirdNET Analyzer, it's going to be a big performance penalty. Hopefully there's something wrong with the numbers? Like, maybe they're reversed? :-) |
Beta Was this translation helpful? Give feedback.
-
|
The numbers are correct. The new system is slower than the old one. But I'm quite sure you wouldn't notice, if it got implemented in BirdNET Analyzer and you rerun your tests from above, because the time to open the file is still much smaller than the time to analyze the content (except for very short files). I only presented the times to open the files 100 times in a range and I limited the CPU to 1,8 GHz to avoid differences because of turbo boost and thermal throttling. To analyze all the files (with 2.5 seconds overlap), you may just add 20 seconds to the first set of presented times and 13800 seconds to the second set of presented times. I'm quite sure you wouldn't notice, whether it takes 13801.488 seconds or 13813.502 seconds to analyze this batch of 100 ten minutes files. Of course, you may notice the difference for 100 one second files analyzed in 20.396 seconds or 29.566 seconds, but this is just why I advise against using 5.1 audio recordings. The difference for 100 one second mono files is much smaller (20.051 seconds compared to 21.458 seconds). |
Beta Was this translation helpful? Give feedback.
-
|
OOhhh... Let me restate your thoughts to see whether I'm understanding. You're testing the difference between the time it takes New versus Old to open files and convert them to mono, but not do any processing beyond that. My test opens the files, converts them to mono (if needed) and processes them. Would it be possible for you to run your New vs Old scenario against the same file that I used? Here's a public download link (the file is a 1-hour 16-bit 635mB stereo WAV file). |
Beta Was this translation helpful? Give feedback.
-
|
I am curious to know how long your files' processing takes when using Chirpity. Because of the way the App uses threads, resampling is not a bottleneck, and inference is typically faster than the Python implementation of the BirdNET Analyzer |
Beta Was this translation helpful? Give feedback.
-
|
Hi Matt, Happy to take this offline. I'd prefer to keep this thread focused on BirdNET-Analyzer performance tips. :-) |
Beta Was this translation helpful? Give feedback.
-
It should be mentioned that recording at 48K does have a size cost if your preferred sample rate is lower. I record at 24k, mono, and 48k would double the file sizes. For me, file size trumps processing speed, and I found that detection accuracy was not materially affected by using the lower rate. But I actually use Chirpity now, which resamples the files itself before handing them to BirdNET - not that this is relevant to the discussion at hand. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This would be a good one for the documentation. Switching the sample-rate to 48k in our recorders cut BirdNET-Analyzer processing time from 48 seconds per (one hour, stereo, WAV) file to 32 seconds. Any other sample-rate forces BirdNET-Analyzer to resample the file to 48k before it can process it. I'm pretty pleased with the result. :-)
Does anybody have performance-tips they would like to share?
Beta Was this translation helpful? Give feedback.
All reactions