如何用双簧管正确播放解码后的内存 PCM?
How to play decoded in-memory PCM with Oboe properly?
我使用oboe to play sounds in my ndk library, and I use OpenSL with Android extensions将wav文件解码成PCM。解码后的签名 16 位 PCM 存储在内存中 (std::forward_list<int16_t>
),然后通过回调将它们发送到双簧管流中。我可以从 phone 听到的声音在音量水平上与原始 wav 文件相似,但是,'quality' 这种声音不是 -- 它是爆裂声和噼啪声。
我猜我以错误的顺序或格式(采样率?)在音频流中发送 PCM。如何将 OpenSL 解码与双簧管音频流一起使用?
为了将文件解码为 PCM,我使用 AndroidSimpleBufferQueue 作为接收器,AndroidFD 和 AAssetManager作为来源:
// Loading asset
AAsset* asset = AAssetManager_open(manager, path, AASSET_MODE_UNKNOWN);
off_t start, length;
int fd = AAsset_openFileDescriptor(asset, &start, &length);
AAsset_close(asset);
// Creating audio source
SLDataLocator_AndroidFD loc_fd = { SL_DATALOCATOR_ANDROIDFD, fd, start, length };
SLDataFormat_MIME format_mime = { SL_DATAFORMAT_MIME, NULL, SL_CONTAINERTYPE_UNSPECIFIED };
SLDataSource audio_source = { &loc_fd, &format_mime };
// Creating audio sink
SLDataLocator_AndroidSimpleBufferQueue loc_bq = { SL_DATALOCATOR_ANDROIDSIMPLEBUFFERQUEUE, 1 };
SLDataFormat_PCM pcm = {
.formatType = SL_DATAFORMAT_PCM,
.numChannels = 2,
.samplesPerSec = SL_SAMPLINGRATE_44_1,
.bitsPerSample = SL_PCMSAMPLEFORMAT_FIXED_16,
.containerSize = SL_PCMSAMPLEFORMAT_FIXED_16,
.channelMask = SL_SPEAKER_FRONT_LEFT | SL_SPEAKER_FRONT_RIGHT,
.endianness = SL_BYTEORDER_LITTLEENDIAN
};
SLDataSink sink = { &loc_bq, &pcm };
然后我注册回调、排队缓冲区并将 PCM 从缓冲区移动到存储,直到完成。
注意:wav 音频文件也是 2 通道签名 16 位 44.1Hz PCM
我的双簧管流配置相同:
AudioStreamBuilder builder;
builder.setChannelCount(2);
builder.setSampleRate(44100);
builder.setCallback(this);
builder.setFormat(AudioFormat::I16);
builder.setPerformanceMode(PerformanceMode::LowLatency);
builder.setSharingMode(SharingMode::Exclusive);
音频渲染是这样工作的:
// Oboe stream callback
audio_engine::onAudioReady(AudioStream* self, void* audio_data, int32_t num_frames) {
auto stream = static_cast<int16_t*>(audio_data);
sound->render(stream, num_frames);
}
// Sound::render method
sound::render(int16_t* audio_data, int32_t num_frames) {
auto iter = pcm_data.begin();
std::advance(iter, cur_frame);
const int32_t rem_size = std::min(num_frames, size - cur_frame);
for(int32_t i = 0; i < rem_size; ++i, std::next(iter), ++cur_frame) {
audio_data[i] += *iter;
}
}
您的 render() 方法似乎混淆了样本和帧。
帧是一组同时采样。
在立体流中,每个帧有两个样本。
我认为您的迭代器是在样本基础上工作的。换句话说,next(iter) 将前进到下一个样本,而不是下一帧。试试这个(未经测试的)代码。
sound::render(int16_t* audio_data, int32_t num_frames) {
auto iter = pcm_data.begin();
const int samples_per_frame = 2; // stereo
std::advance(iter, cur_sample);
const int32_t num_samples = std::min(num_frames * samples_per_frame,
total_samples - cur_sample);
for(int32_t i = 0; i < num_samples; ++i, std::next(iter), ++cur_sample) {
audio_data[i] += *iter;
}
}
简而言之: 本质上,由于使用 std::forward_list
存储 PCM,我遇到了数据不足。在这种情况下(使用迭代器检索 PCM),必须使用其迭代器实现 LegacyRandomAccessIterator(例如 std::vector
)的容器。
我确信方法 std::advance
和 std::next
的线性复杂性在我的 sound::render
方法中没有任何区别。但是,当我尝试将原始指针和指针算法(因此,复杂性不变)与评论中建议的调试方法一起使用时(Extracting PCM from WAV with Audacity, then loading this asset with AAssetManager 直接存入内存),我意识到,"corruption" 的输出声音量与 render 方法中 std::advance(iter, position)
中的 position 参数成正比。
因此,如果声音损坏的数量与 std::advance
(以及 std::next
)的复杂性成正比,那么我必须使复杂性保持不变——通过使用 std::vector
作为容器。并使用@philburk 的回答,我得到了这个作为工作结果:
class sound {
private:
const int samples_per_frame = 2; // stereo
std::vector<int16_t> pcm_data;
...
public:
render(int16_t* audio_data, int32_t num_frames) {
auto iter = std::next(pcm_data.begin(), cur_sample);
const int32_t s = std::min(num_frames * samples_per_frame,
total_samples - cur_sample);
for(int32_t i = 0; i < s; ++i, std::advance(iter, 1), ++cur_sample) {
audio_data[i] += *iter;
}
}
}
我使用oboe to play sounds in my ndk library, and I use OpenSL with Android extensions将wav文件解码成PCM。解码后的签名 16 位 PCM 存储在内存中 (std::forward_list<int16_t>
),然后通过回调将它们发送到双簧管流中。我可以从 phone 听到的声音在音量水平上与原始 wav 文件相似,但是,'quality' 这种声音不是 -- 它是爆裂声和噼啪声。
我猜我以错误的顺序或格式(采样率?)在音频流中发送 PCM。如何将 OpenSL 解码与双簧管音频流一起使用?
为了将文件解码为 PCM,我使用 AndroidSimpleBufferQueue 作为接收器,AndroidFD 和 AAssetManager作为来源:
// Loading asset
AAsset* asset = AAssetManager_open(manager, path, AASSET_MODE_UNKNOWN);
off_t start, length;
int fd = AAsset_openFileDescriptor(asset, &start, &length);
AAsset_close(asset);
// Creating audio source
SLDataLocator_AndroidFD loc_fd = { SL_DATALOCATOR_ANDROIDFD, fd, start, length };
SLDataFormat_MIME format_mime = { SL_DATAFORMAT_MIME, NULL, SL_CONTAINERTYPE_UNSPECIFIED };
SLDataSource audio_source = { &loc_fd, &format_mime };
// Creating audio sink
SLDataLocator_AndroidSimpleBufferQueue loc_bq = { SL_DATALOCATOR_ANDROIDSIMPLEBUFFERQUEUE, 1 };
SLDataFormat_PCM pcm = {
.formatType = SL_DATAFORMAT_PCM,
.numChannels = 2,
.samplesPerSec = SL_SAMPLINGRATE_44_1,
.bitsPerSample = SL_PCMSAMPLEFORMAT_FIXED_16,
.containerSize = SL_PCMSAMPLEFORMAT_FIXED_16,
.channelMask = SL_SPEAKER_FRONT_LEFT | SL_SPEAKER_FRONT_RIGHT,
.endianness = SL_BYTEORDER_LITTLEENDIAN
};
SLDataSink sink = { &loc_bq, &pcm };
然后我注册回调、排队缓冲区并将 PCM 从缓冲区移动到存储,直到完成。
注意:wav 音频文件也是 2 通道签名 16 位 44.1Hz PCM
我的双簧管流配置相同:
AudioStreamBuilder builder;
builder.setChannelCount(2);
builder.setSampleRate(44100);
builder.setCallback(this);
builder.setFormat(AudioFormat::I16);
builder.setPerformanceMode(PerformanceMode::LowLatency);
builder.setSharingMode(SharingMode::Exclusive);
音频渲染是这样工作的:
// Oboe stream callback
audio_engine::onAudioReady(AudioStream* self, void* audio_data, int32_t num_frames) {
auto stream = static_cast<int16_t*>(audio_data);
sound->render(stream, num_frames);
}
// Sound::render method
sound::render(int16_t* audio_data, int32_t num_frames) {
auto iter = pcm_data.begin();
std::advance(iter, cur_frame);
const int32_t rem_size = std::min(num_frames, size - cur_frame);
for(int32_t i = 0; i < rem_size; ++i, std::next(iter), ++cur_frame) {
audio_data[i] += *iter;
}
}
您的 render() 方法似乎混淆了样本和帧。 帧是一组同时采样。 在立体流中,每个帧有两个样本。
我认为您的迭代器是在样本基础上工作的。换句话说,next(iter) 将前进到下一个样本,而不是下一帧。试试这个(未经测试的)代码。
sound::render(int16_t* audio_data, int32_t num_frames) {
auto iter = pcm_data.begin();
const int samples_per_frame = 2; // stereo
std::advance(iter, cur_sample);
const int32_t num_samples = std::min(num_frames * samples_per_frame,
total_samples - cur_sample);
for(int32_t i = 0; i < num_samples; ++i, std::next(iter), ++cur_sample) {
audio_data[i] += *iter;
}
}
简而言之: 本质上,由于使用 std::forward_list
存储 PCM,我遇到了数据不足。在这种情况下(使用迭代器检索 PCM),必须使用其迭代器实现 LegacyRandomAccessIterator(例如 std::vector
)的容器。
我确信方法 std::advance
和 std::next
的线性复杂性在我的 sound::render
方法中没有任何区别。但是,当我尝试将原始指针和指针算法(因此,复杂性不变)与评论中建议的调试方法一起使用时(Extracting PCM from WAV with Audacity, then loading this asset with AAssetManager 直接存入内存),我意识到,"corruption" 的输出声音量与 render 方法中 std::advance(iter, position)
中的 position 参数成正比。
因此,如果声音损坏的数量与 std::advance
(以及 std::next
)的复杂性成正比,那么我必须使复杂性保持不变——通过使用 std::vector
作为容器。并使用@philburk 的回答,我得到了这个作为工作结果:
class sound {
private:
const int samples_per_frame = 2; // stereo
std::vector<int16_t> pcm_data;
...
public:
render(int16_t* audio_data, int32_t num_frames) {
auto iter = std::next(pcm_data.begin(), cur_sample);
const int32_t s = std::min(num_frames * samples_per_frame,
total_samples - cur_sample);
for(int32_t i = 0; i < s; ++i, std::advance(iter, 1), ++cur_sample) {
audio_data[i] += *iter;
}
}
}