Saving a slice of frames in a single operation, and removed fsync #19
Conversation
This has huge performance benefits over doing it a frame at a time.
... or do any system-level stuff with the files, because they do not know the specifics, for example where, on which file system or network device the files are being stored. Only the file creator knows that.
Codecov Report
@@ Coverage Diff @@
## master #19 +/- ##
=======================================
- Coverage 58.84% 56% -2.85%
=======================================
Files 6 6
Lines 622 650 +28
=======================================
- Hits 366 364 -2
- Misses 160 190 +30
Partials 96 96
Continue to review full report at Codecov.
|
|
Thanks a lot for the PR, I like the direction, I am a bit surprised that a frame is equal to a sample, that doesn't seem right in the case of a file with more than 1 channel (a frame is a sample * num channels). I need to try to remember why I was syncing when setting up the metadata, it doesn't seem to make a lot of sense but I will try to dig through the history. Finally, any chance you could add some tests to make sure the code behaves as expected, especially with the type of frames. |
|
It was just a single sample in my case where I have a single channel. I handled the case with multiple channels partially - some checks are needed that the slice length is sane. The original issue is just a side effect of Go's binary.Write() accepting both simple types (like integers) and slices of those, transparently. I'll add the tests and submit another PR. |
| @@ -1,4 +1,4 @@ | |||
| module github.com/go-audio/wav | |||
| module github.com/ivoras/wav | |||
See commit descriptions and issue #18 for details.