Doubt about sampling bits and SineWaveGenerator constructor (and maybe other constructors as well)

[mgesteiro]

Hi there, Phil

First things first: many thanks for all your work in this framework, it's helping us a lot by making our efforts a lot easier.

Now the question:
Working with the SineWaveGenerator class I came across a situation where it's not clear (at least to me) how the set-up/configuration process/flow should be done, which triggered and even deeper doubt about how to operate the whole framework. This particular class has a constructor with two default parameters, amplitude and phase. The amplitude has a default value that is 90% of the maximum amplitude... BUT: this maximum is calculated from the base type of the class (8, 16, ...), ignoring the bits_per_sample parameter that should "rule" the whole thing, right?

My doubts are:

• What if the bit_per_sample are, for example, 20 (or 12, or 10... i.e. some value smaller than the maximum base type), won't this clip the wave being generated?
• Should or should not the bits_per_sample rule all amplitude related operations in the framework?
• If the previous answer is yes, where should initialization take place? constructor, begin(), other?

I've read quite a lot of the wiki and the source code but it's still not clear to me (it's already a big framework), and maybe I'm getting it all wrong, so that's why I decided to ask: if I want a 10 or 12 bit kind of audio, I assume I need to use int16_t as the base type for all my classes (minimum able to cover my needs), but also establishing that "hard limit" (10/12) in the bits_per_sample field in the AudioInfo config, right? I'm also lost with where should I put "initialization" code: constructor, begin(), etc. and what happens if retrieving methods of a class (e.g. readSample()) are called without the begin() method being invoked beforehand.

I'm working on a new class based on SineWaveGenerator to generate different kinds of tone, and I would appreciate some clarity about where should I initialize things and a strategy to do so in a consistent and robust way that works well with the underlying Audio-Tools framework.

Best regards!

[pschatzmann]

The max amplitude is just a convenient way to define the volume e.g. in a test sketch. My recommendation would be to use the max volume and modify the volume with a VolumeStream. If you have some doubts, I suggest to have a look at the different examples.

The bits_per_sample in the configuration is mainly relevant for the untyped classes, but it is recommended to keep things consistent: 12 or 10 is nonsense. The only meaningful values in audio are 16, 24 and 32.

[mgesteiro]

I see.

The ESP32 internal ADC is 12 bit, and yes, you convert it (e.g. https://github.com/pschatzmann/arduino-audio-tools/tree/main/examples/examples-basic-api/base-adc-serial) but, why do you say it is "nonsense"? (I'd like to understand 🤷🏽‍♂️).

I already use VolumeStream for audio files, but for my ToneGenerator, the amplitude parameter was more convenient as it's prefixed and saves me a step. The examples I already reviewed are sometimes inconsistent and not all the code is correctly documented, so that's confusing: I'm not sure when begin is required or constructors are enough (or with which parameters). There are also other myriad of little things: return types, how to correctly stop [and clear?] an audio stream, etc. Most of these are going by trial/error, but wanted to do better (what I came here for!).

Please, don't get me wrong: I'm more than happy with how it is right now, and I don't expect any specific support, I'm just explaining myself in case it provides you an useful outside view. Your answer already provided us valuable insight (we'll only use 16 bit for our little project 👌).

Thanks!

[pschatzmann]

Did you already read the Wiki ? The bits_per_sample just describes the supported integer types which are int16_t, int24_t and int32_t. This corresponds with https://docs.espressif.com/projects/esp-idf/en/v4.2/esp32/api-reference/peripherals/i2s.html#_CPPv421i2s_bits_per_sample_t

[mgesteiro]

Yes, I read the Wiki, and also went into the source code:

AudioInfo.bits_per_sample in AudioTypes.h is not an enum, but an int.

And in the Expressif documentation you mention, int8_t is also supported: I2S_BITS_PER_SAMPLE_8BIT (so 8, 16, 24 and 32)

That's not consistent 🤷🏽‍♂️

In any case, now I know: thanks for taking the time to point out that only fixed values are allowed! Maybe, this little (and important) piece of information should be clearly stated in the Wiki (at least in the Introduction). Please, bear in mind that maybe is obvious to you (or believe that it's been made obvious), but it helps more than anything to state some obvious things to other people.

Bes regards!

[pschatzmann]

The 8bits in the ESP32 is only working to my knowledge in some exceptional cases, so I would not recommend to rely on this
and use it only when you know what you are doing!

The enum that I sent you is just an example for the esp32 i2s, that I used as a base line.
In general I recommend to stick with 16 bits unless you have a good reason for something else. E.g there are some I2S ADCs that produce noise with 16 bit and only work correctly with 32bits.

In the first chapter of the Wiki I describe the PCM data format!

[G-Roman1988]

mgesteiro is right with his ideas that it would be much more flexible to work with the library, which is good, but little things are missing.

[G-Roman1988]

mgesteiro is right with his ideas that it would be much more flexible to work with the library, which is good, but little things are missing.

[G-Roman1988]

mgesteiro is right with his ideas that it would be much more flexible to work with the library, which is good, but little things are missing.

[pschatzmann]

This is an open source project! If you feel that anything is missing feel free to contribute.
If you look at the source code you will discover that it is logically structured and easy to extend...