Skip to content

Audio file incremental reading #294

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Aug 4, 2020
Merged

Audio file incremental reading #294

merged 2 commits into from
Aug 4, 2020

Conversation

jpcima
Copy link
Collaborator

@jpcima jpcima commented Jun 24, 2020

This supports incremental file loading. The availableFrames will be incremented as the file is being read.
Reading and oversampling operations are going to be processed in turns, on the basis of 1024 frames segments.

This supports 3 reading strategies

  • forward
  • reverse, by seeking backward starting from EOF (if the format supports this well)
  • reverse by reading the whole file first (like currently)

This allows long files to played, improving the ogg playback ability in particular, but there can be still trouble in the high frequency range. An increased preload size helps a lot, but it can still be a miss even at the highest setting, starting at octaves ~ 6-7.

@jpcima jpcima force-pushed the incremental-file-load branch 2 times, most recently from 79a094d to 367f404 Compare June 24, 2020 11:07
@jpcima jpcima force-pushed the incremental-file-load branch from 367f404 to 2873c97 Compare June 24, 2020 11:19
@paulfd
Copy link
Member

paulfd commented Jul 1, 2020

Looks nice. I prepped a way to benchmark the performance over the commits, to see where we loose and if we accept it (also for performance-impacting things in develop such as the smoothers, voice stealing, etc).

I don't know if you've checked the benchmarks I made for this before, comparing reading at once with reading in chunks. This is for a wav file (disregard the "AllocInside" it does not matter).

Benchmark                               Time             CPU   Iterations
-------------------------------------------------------------------------
FileFixture/JustRead              1322589 ns      1314062 ns          507
FileFixture/AllocInside/256       4251651 ns      4244179 ns          166
FileFixture/AllocInside/1024      3333125 ns      3327310 ns          211
FileFixture/AllocInside/4096      3148030 ns      3142523 ns          223
FileFixture/AllocInside/16384     3056656 ns      3051190 ns          229
FileFixture/AllocInside/65536     3048152 ns      3042869 ns          229

and this is for a flac file

FileFixture/SndFileOnce             1954472 ns      1941911 ns          329
FileFixture/SndFileChunked/1024    26315707 ns     26269155 ns           26
FileFixture/SndFileChunked/4096    26028601 ns     25984978 ns           27
FileFixture/SndFileChunked/16384   25974007 ns     25928478 ns           27
FileFixture/SndFileChunked/65536   25998185 ns     25952121 ns           27

For FLAC you do take a substantial hit, but if it takes 10 times longer to load overall but you miss no deadlines on the way it might be OK.

@jpcima
Copy link
Collaborator Author

jpcima commented Jul 1, 2020

It's a dumb program which I made before for quick comparisons.
CompareReaders.cpp.gz

I didn't take time to turn this into a proper benchmark.
Also the result is certainly biased, because the 2nd read will be cached at the filesystem level.

Regardless, the conclusion is like you said, flac takes a hit.
It was the same observation regarding all compressed formats; except ogg, which was incredibly slow, as if it decodes the whole again on every seek.

For the actual benchmark, I wished a program that will pre-convert the reference flac into all formats, and it will derive it into a benchmark of all formats. (but explicitly skip reverse ogg, this one takes minutes)

@paulfd paulfd modified the milestones: 0.5.0, 0.4.1 Jul 8, 2020
@jpcima
Copy link
Collaborator Author

jpcima commented Jul 25, 2020

Below the benchmarks.
There's one thing that seems fishy though, loading the entire file at once turns out slower.

Also perhaps sine wave files don't have best properties when it comes to evaluating compressed files, I didn't really check this aspect of thing currently.

Backward ogg removed because it's extremely slow.

2020-07-26 01:18:51
Running ./build/benchmarks/bm_audioReaders
Run on (8 X 3600 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x4)
  L1 Instruction 64 KiB (x4)
  L2 Unified 512 KiB (x4)
  L3 Unified 4096 KiB (x1)
Load Average: 1.52, 1.19, 1.21
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead.
------------------------------------------------------------------------------
Benchmark                                    Time             CPU   Iterations
------------------------------------------------------------------------------
AudioReaderFixture/ForwardWav/64       2693133 ns      2674927 ns          255
AudioReaderFixture/ForwardWav/128      1747656 ns      1737513 ns          363
AudioReaderFixture/ForwardWav/256      1192438 ns      1186371 ns          606
AudioReaderFixture/ForwardWav/512      1074858 ns      1066319 ns          607
AudioReaderFixture/ForwardWav/1024      964548 ns       958246 ns          681
AudioReaderFixture/ReverseWav/64       4408984 ns      4381626 ns          162
AudioReaderFixture/ReverseWav/128      2908945 ns      2889647 ns          245
AudioReaderFixture/ReverseWav/256      1818282 ns      1808423 ns          325
AudioReaderFixture/ReverseWav/512      1379346 ns      1372786 ns          488
AudioReaderFixture/ReverseWav/1024     1136234 ns      1130133 ns          598
AudioReaderFixture/EntireWav/1         1335103 ns      1316409 ns          524
AudioReaderFixture/ForwardFlac/64      8797697 ns      8749066 ns           80
AudioReaderFixture/ForwardFlac/128     8940622 ns      8886647 ns           79
AudioReaderFixture/ForwardFlac/256     9031402 ns      8776849 ns           80
AudioReaderFixture/ForwardFlac/512     8996212 ns      8684957 ns           78
AudioReaderFixture/ForwardFlac/1024    9081214 ns      8795719 ns           80
AudioReaderFixture/ReverseFlac/64    725871795 ns    720771954 ns            1
AudioReaderFixture/ReverseFlac/128   352124986 ns    350114019 ns            2
AudioReaderFixture/ReverseFlac/256   178118364 ns    177300601 ns            4
AudioReaderFixture/ReverseFlac/512    92904061 ns     92351383 ns            8
AudioReaderFixture/ReverseFlac/1024   54126562 ns     53711445 ns           13
AudioReaderFixture/EntireFlac/1        9799830 ns      9622875 ns           61
AudioReaderFixture/ForwardOgg/64      12982565 ns     12775717 ns           55
AudioReaderFixture/ForwardOgg/128     12878953 ns     12671732 ns           55
AudioReaderFixture/ForwardOgg/256     12949429 ns     12738415 ns           55
AudioReaderFixture/ForwardOgg/512     12893078 ns     12695587 ns           53
AudioReaderFixture/ForwardOgg/1024    12857407 ns     12647284 ns           55
AudioReaderFixture/EntireOgg/1        13605300 ns     13300714 ns           52

@paulfd
Copy link
Member

paulfd commented Jul 26, 2020

I'll run some file loading benchmarks "live".

@paulfd
Copy link
Member

paulfd commented Aug 2, 2020

The benchmarks looked OK but I forgot to post them before leaving. I think we could merge this and give it some runtime until the next point release.

@jpcima
Copy link
Collaborator Author

jpcima commented Aug 4, 2020

Sure let's merge it.
As a suspicion I had a bit ago, perhaps sndfile FD-based API is the origin of observed differences.

@jpcima jpcima merged commit 73dd5da into sfztools:develop Aug 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@paulfd paulfd paulfd approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@jpcima @paulfd