Thanks, Remi!

In c39f01daa6ce011960e852bfc6147a96769b0955

ZSTD_minCLevel() and ZSTD_maxCLevel() are from zstd 1.5

From https://github.com/facebook/zstd/commit/9bb6c15f7966f59d001f782f087484a414eba570 The commit which introduces this function is in 1.3.6

Notice: and, at least, I can confirm libzip 1.8.0 work as expected (build + test suite) on RHEL / CentOS 8 which have 1.4.4

Missing zstd functions appeared in zstd 1.5.x

They are in 1.3.6

In ChangeLog

v1.3.6  (Oct 6, 2018)
...
api : minimum negative compression level is defined, and can be queried using ZSTD_minCLevel().

And ZSTD_maxCLevel was already there

In c39f01daa6ce011960e852bfc6147a96769b0955

ZSTD_minCLevel() and ZSTD_maxCLevel() are from zstd 1.5

From https://github.com/facebook/zstd/commit/9bb6c15f7966f59d001f782f087484a414eba570 The commit which introduces this function is in 1.3.6

Notice: and, at least, I can confirm libzip 1.8.0 work as expected (build + test suite) on RHEL / CentOS 8 which have 1.4.4

Compiler Error Linker error: ZSTD_minCLevel() and ZSTD_maxCLevel() not found

libzip Version 1.8.0

Operating System and Compiler Ubuntu 18.04, platform provided zstd lib 1.3.3

Also, any flags passed to cmake. -DBUILD_SHARED_LIBS:BOOL=ON
-DBUILD_TOOLS=ON
-DBUILD_REGRESS=OFF
-DBUILD_EXAMPLES=OFF
-DBUILD_DOC=OFF \

Additional context Missing zstd functions appeared in zstd 1.5.x while ubunutu 18.04 has 1.3.3 -> link errors need to add zstd version requirement to CMakeLists.txt: from: "find_package(Zstd)" to: "find_package(Zstd 1.5)" this will automatically disable older and incompatible zstd lib versions

Compiler Error Linker error: ZSTD_minCLevel() and ZSTD_maxCLevel() not found

libzip Version 1.8.0

Operating System and Compiler Ubuntu 18.04, platform provided zstd lib 1.3.3

Also, any flags passed to cmake. -DBUILD_SHARED_LIBS:BOOL=ON
-DBUILD_TOOLS=ON
-DBUILD_REGRESS=OFF
-DBUILD_EXAMPLES=OFF
-DBUILD_DOC=OFF \

Additional context Missing zstd functions appeared in zstd 1.5.x while ubunutu 18.04 has 1.3.3 -> link errors need to add zstd version requirement to CMakeLists.txt: from: "find_package(Zstd)" to: "find_package(Zstd 1.5)" this will automatically disable older and incompatible zstd lib versions

https://github.com/nih-at/libzip/blob/d2da5594caa1f6d3fe3285f89600108b21b396e4/lib/zip_source_file_win32.c#L101-L118

Fixed, thanks!

https://github.com/nih-at/libzip/blob/d2da5594caa1f6d3fe3285f89600108b21b396e4/lib/zip_source_file_win32.c#L101-L118

Decode the format type field, and the block align field.

Ref:

• http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html
• https://wavefilegem.com/how_wave_files_work.html

Well that's a disappointing cop out. Considering that SAT-SMART Driver is no longer supported here and when it was there was no need to approve it in Security & Privacy, this is close to the last place I would send anybody for such an issue.

I take it that SAT-SMART isn't working for you with regard to a USB external drive. It's been at least a couple of years since I installed the DriveDX version in Mojave (or perhaps an earlier macOS) so I don't even recall if such approval was required at the time. In checking my Mojave setup today I see that I have a signed 0.10 driver installed in /System/Library/Extensions, /Library/Extensions and /Library/StagedExtensions/Library/Extensions. I'm certain that the first is left over from an earlier installation when installing in /System by an admin was still allowed. Just the other day I cleaned out my extensions to get rid of any that were no longer needed using sudo kextcache --clear-staging and rebooting to rebuild the cache, so the /Library portion should be up-to-date.

Recommend you check the Console for any error messages referencing a kext... process in conjunction with SAT-SMART. Assuming that Drivers are treated the same as Kernel Extensions and Mojave behaves the way High Sierra did, this Tech Note might be of use: https://developer.apple.com/library/archive/technotes/tn2459/_index.html.

I've set up my hardware to generate 48kHz PCM stream, within only 1 channel. Therefore, it generates 48000 / 320 = 150 frames per second. The problem is that I get OPUS_BAD_ARG from opus_encode caused by this piece of code:

https://github.com/xiph/opus/blob/61747bc6ec728de69d54db6ece90ad4617f059b8/src/opus_encoder.c#L629

libopus thinks that 150 frames per second is invalid. Is it possible to solve the problem?

How to reproduce

#include <opus/opus.h>

#include <assert.h>
#include <stdlib.h>
#include <stdio.h>

#define FILE_SIZE (320 * 1000)
#define FRAMES_COUNT 500
#define FRAME_SIZE 320

int main(void) {
	int error;
	OpusEncoder *enc;
	enc = opus_encoder_create(48000, 1, OPUS_APPLICATION_AUDIO, &error);
	assert(error == OPUS_OK);

	FILE *fp = fopen("audio.pcm", "rb");
	assert(fp);

	char *data = malloc(FILE_SIZE);
	assert(data);
	fread(data, 1, FILE_SIZE, fp);

	char *out = malloc(4000);
	assert(out);

	for (size_t i = 0; i < FRAMES_COUNT; i++) {
		int bytes_written = opus_encode(enc, data + (i * FRAME_SIZE), FRAME_SIZE, out, 4000);
		if (bytes_written < 0) {
			if (bytes_written == OPUS_BAD_ARG) {
				abort(); // Fails
			}
		}
	}
}

The stream itself: audio.pcm.tar.gz.

Compiling:

$ gcc test_opus.c -lopus

Thanks, with frame size = 960 it worked.

Another issue is that the third argument to opus_encode is the number of samples, not the number of bytes. If you're reading 16-bit mono audio into a char * you need to divide by two when you pass the in input frame size.

In fact, FRAME_SIZE here is the number of samples, but I provide data + (i * FRAME_SIZE) as the second argument to opus_encode, which is wrong; data + (i * FRAME_SIZE * 2) would be correct.

Thank you, merged!

Currently cmake provides an pc file with: Libs.private: -lbz2 -llzma -lZstd::Zstd -lz

No, it's not possible to run the encoder at 150 frames a second. You must use a supported frame size. If your hardware isn't capable of using one of the possible frame sizes, you can insert a small ringbuffer to compensate.

We recommend 960 sample frames (20 ms at 48 kHz, or 50 frames per second) for most applications. Frames shorter than 10 ms reduce quality with little improvement to delay unless you're doing live audio.

int bytes_written = opus_encode(enc, data + (i * FRAME_SIZE), FRAME_SIZE, out, 4000);

Another issue is that the third argument to opus_encode is the number of samples, not the number of bytes. If you're reading 16-bit mono audio into a char * you need to divide by two when you pass the in input frame size.

I've set up my hardware to generate 48kHz PCM stream, within only 1 channel. Therefore, it generates 48000 / 320 = 150 frames per second. The problem is that I get OPUS_BAD_ARG from opus_encode caused by this piece of code:

https://github.com/xiph/opus/blob/61747bc6ec728de69d54db6ece90ad4617f059b8/src/opus_encoder.c#L629

libopus thinks that 150 frames per second is invalid. Is it possible to solve the problem?

How to reproduce

#include <opus/opus.h>

#include <assert.h>
#include <stdlib.h>
#include <stdio.h>

#define FILE_SIZE (320 * 1000)
#define FRAMES_COUNT 500
#define FRAME_SIZE 320

int main(void) {
	int error;
	OpusEncoder *enc;
	enc = opus_encoder_create(48000, 1, OPUS_APPLICATION_AUDIO, &error);
	assert(error == OPUS_OK);

	FILE *fp = fopen("audio.pcm", "rb");
	assert(fp);

	char *data = malloc(FILE_SIZE);
	assert(data);
	fread(data, 1, FILE_SIZE, fp);

	char *out = malloc(4000);
	assert(out);

	for (size_t i = 0; i < FRAMES_COUNT; i++) {
		int bytes_written = opus_encode(enc, data + (i * FRAME_SIZE), FRAME_SIZE, out, 4000);
		if (bytes_written < 0) {
			if (bytes_written == OPUS_BAD_ARG) {
				abort(); // Fails
			}
		}
	}
}

The stream itself: audio.pcm.tar.gz.

Compiling:

$ gcc test_opus.c -lopus

Currently cmake provides an pc file with: Libs.private: -lbz2 -llzma -lZstd::Zstd -lz