I will agree that it sounds inefficient. I haven't had any issues personally though. At least with smaller files. It seems like this file would need to under go serious changes: https://github.com/ioctlLR/NVorbis/blob/master/NVorbis/VorbisStreamDecoder.cs.
Do we really know that this is an issue though? It's not the only ogg Vorbis library I've seen that only reads samples to a float buffer. I fully agree that it would be better to read to a 16 bit buffer directly but I'm limited on the amount of time I can put into NVorbis. You’re more knowledgeable in audio decoding than I am. If you want to start something, then I can try to find some time to help and then merge it, but I can't stop working on my game to work on something that might not even be problem. If it becomes one, then I’ll do all I can. I'm sorry.
Slower loading times are not ideal but once the buffer is converted I imagine you won't be wasting memory or much performance on playing the sound.
I am streaming the audio data inside a game. So it’s a continuous waste of performance😄
It's the default format because it guarantees that all ogg files can be read without loss. I think the question is not whether there is a performance loss but how much of one? Is it worth writing new code to save what could be an almost irrelevant amount of time? I need to implement streaming into my engine at some point so if you prove to me that this is an issue then I will gladly try to fix it.
I can do the conversion myself for now, but the next guy that wants to feel the stream in any audio library will have the same issue
The official ogg implementation's method for loading uses a float buffer: https://github.com/xiph/vorbis/blob/ea8b03fce93444cb3cf0131909e15b4f8856e863/include/vorbis/codec.h#L211
The official higher level ogg implementation converts the float data:
https://github.com/xiph/vorbis/blob/master/lib/vorbisfile.c#L1963
https://github.com/xiph/vorbis/blob/master/lib/vorbisfile.c#L1963
Here is that first method being used to load WebM audio (which is vorbis) in the Godot engine. The float buffer is then converted to a 16 bit int buffer: https://github.com/godotengine/godot/blob/4f5a7ebaecfcf00cf1e5c4af4b20034f0dcecd29/thirdparty/libsimplewebm/OpusVorbisDecoder.cpp#L90
Here is also the code used to load standalone ogg data. It has a method for a 16 bit int buffer but all it does is convert the float buffer. https://github.com/godotengine/godot/blob/4f5a7ebaecfcf00cf1e5c4af4b20034f0dcecd29/thirdparty/misc/stb_vorbis.c#L5210
And another library I found earlier: https://github.com/jfreymuth/oggvorbis/blob/master/reader.go#L127
public override long GetSamples(int samples, out byte[] data)
{
int bytes = _audioFormat.BytesPerSample * samples;
data = new byte[bytes];
var readBuf = new float[samples];
_reader.ReadSamples(readBuf, 0, samples);
CastBuffer(readBuf, data, samples);
return samples;
}
two rather large allocations in one function
For streaming purposes you would reuse both buffers. You wouldn't reallocate them.
https://github.com/ioctlLR/NVorbis/blob/master/OpenTKSupport/OggStream.cs#L330
https://github.com/ioctlLR/NVorbis/blob/master/OpenTKSupport/OggStream.cs#L330
Do you know if Array.Resize skips any allocation if the buffer size to subsequent calls is the same?
I support both 8 & 16 bit
"If newSize is greater than the Length of the old array, a new array is allocated and all the elements are copied from the old array to the new one. If newSize is less than the Length of the old array, a new array is allocated and elements are copied from the old array to the new one until the new one is filled; the rest of the elements in the old array are ignored. If newSize is equal to the Length of the old array, this method does nothing."
Well I hope this works out alright for you. I'm quite confident it will if you manage the allocations since casting seems to be the official way of doing this. I'm going to try and get audio streaming into my engine this week and see what happens. No promises though. I am considering adding a utility class to cast the samples. I think that might be a little out of scope of the project, but I agree that everyone using the library shouldn't need their own casting method.
I'll try to switch to Span<T> to avoid even more allocations
Absolute worst-case scenario we can try and modify the library, but it looks like that'd be a difficult change. Especially when trying to keep it clean and not break compatibility. It's worth mentioning though that Concentus seems to decode only to short[]. Decoding to float[] is just casting short[] at a loss and byte[] doesn't seem to be supported without a custom casting method. I just skimmed through the decoding code, so I may be wrong, but the creator seems to have oddly done the opposite of everyone else.
Option 1 would go right on the Vorbis reader class. I'm not sure how I feel about this since it hides an extra allocation.
int ReadSamples(short[] buffer, int offset, int count);
int ReadSamples(short[] buffer, int offset, int count, float[] converstionBuffer);
int ReadSamples(int[] buffer, int offset, int count);
int ReadSamples(int[] buffer, int offset, int count, float[] converstionBuffer);
int ReadSamples(byte[] buffer, int offset, int count);
int ReadSamples(byte[] buffer, int offset, int count, float[] converstionBuffer);
int ReadSamples(short[] buffer, int offset, int count);
int ReadSamples(short[] buffer, int offset, int count, float[] converstionBuffer);
int ReadSamples(int[] buffer, int offset, int count);
int ReadSamples(int[] buffer, int offset, int count, float[] converstionBuffer);
int ReadSamples(byte[] buffer, int offset, int count);
int ReadSamples(byte[] buffer, int offset, int count, float[] converstionBuffer);
Option 2 would be a static class named along the lines of VorbisFormatUtility. I don't really like the idea of just throwing in some new static class.
void ConvertPCM(float[] source, short[] destination, int length);
void ConvertPCM(float[] source, int[] destination, int length);
void ConvertPCM(float[] source, byte[] destination, int length);
void ConvertPCM(float[] source, short[] destination, int length);
void ConvertPCM(float[] source, int[] destination, int length);
void ConvertPCM(float[] source, byte[] destination, int length);
Names are not final.
I think I'm leaning more towards option 1 but maybe only use the overload with conversionBuffer .
int ReadSamples(byte[] buffer, int offset, int count);OggStream : Stream like https://github.com/ZaneDubya/MP3Sharp does it.
I am really struggling with the
float[] PCM data failing to glue it into OpenRA and I bet I am not the only one.
Anyone here?
I'm looking for more guidance on ogg
The example on the git is a bit ambiguous.
I'd like to merge multiple ogg files into a single ogg file. Can anyone help me with that?