Quick note for testers with ESP12 about hman-stomper HOT 17 CLOSED

@ErichHeinemann
( @earlephilhower )
I can confirm that the mixer works with noDAC, in fact it seems to work better with noDAC than DAC.. However there is still a lot to do: I have made some code with SPIFF and some sound samples and a few directives to test switching on channels .
https://github.com/dagnall53/mixtest2
My conclusion is that the mixer is currently adding "clicks" somehow and is perhaps not altering its operation when only a few channels are functional.
If you get the chance to test this I would appreciate any comments..
I am using the ESP-12, so I appreciate you may not have the hardware...

from hman-stomper.

Hi guys. I just wanted to say that I am following your changes but just swamped with other things for a bit. I'll be happy to jump on this once those free up! Thx!

from hman-stomper.

Hi all, my proble, - I cannot rebuild it. No ESP12 and I have renamed all my Classes because of to many issues ... . I believe the problem is in the Output. I had changed my code in the AudioOutput.h/.cpp and had added or changed a Mute-Function. I have added my last code which has an added "Sample" in front of the "Audio". Check this here: https://github.com/ErichHeinemann/hman-stomper/blob/master/AdditionalLibs/ESP32SampleAudio/SampleAudioOutputI2Sesp32.cpp

Some new functions are implemented there:
bool AudioOutputI2Sesp32::stop()
{
if (i2sOn){
i2s_zero_dma_buffer((i2s_port_t)I2S_PORT_NUM);
} ...

which probably only works with the real DAC. I have not implemented a corresponding function in the NoDAC-Class.

Excuse me, for now I cannot help out to fix this issue.

from hman-stomper.

Dagnal, compare my code for the AudioOutput.h-File and the real implementation for the DAC. .. I believe the stop is implemented. "mute" was removed in the implementation. A mute-function would look like this:
bool AudioOutputI2Sesp32::mute()
{
if (i2sOn){
i2s_zero_dma_buffer((i2s_port_t)I2S_PORT_NUM);
}
return true;
}

from hman-stomper.

i2s_zero_dma_buffer((i2s_port_t)I2S_PORT_NUM);

FWIW that should quiet down the NoDAC one as well...no transitions = 0 AC component = no noise.

from hman-stomper.

I will look tomorrow, but remember this is way out of my comfort zone!
I will try to add in this function and see if it compiles and works, but I may have to ask "stupid" questions later..

from hman-stomper.

@earlephilhower @ErichHeinemann
OK.. Ive got stuck... but hope when you get the time you can see what is wrong..
I did modify the ::stops, (code below) but to no effect.

Following some experiments, my conclusion is that there is an issue in the mixer codes, but I can not home in on it. There is certainly some sort of timing issue, as I get (very) different results if I put a small delay in the main loop.

Mods to ::Stop in DAC and noDAC, with this code have made no difference:
`// ESP32 Mute function code from Erich Heinemann edited (hacked) to add ESP8266 Dagnall untested with esp32

#ifdef ESP32
if (i2sOn){
i2s_zero_dma_buffer((i2s_port_t)I2S_PORT_NUM);
}
return true;
#else
if (i2sOn){
// uint32_t s32 = (0x0000);
i2s_write_sample_nb(0x0000);
}
return true;

#endif
// mute function end-`
With two channels running I might compare the clicks to perhaps a "gallop", with some syncopation.. With just one channel, this clicking goes, but there is still an underlying quiet noise modulation at about the same rate as the click.

I did try to see if the clicks were loop() related by adding a delay(1) in the main loop.

With just one channel on, and delay(1), there is no change. there are clicks when the files are started but the sounds play and loop.
With two channels on, and delay(1) I get just a continuous 440 hz approx tone. and the serial monitor shows that the wav files are not looping as expected, they seem "stuck".

With delay(10) and a single channel, I see the "sink->stop send" debug message (I have not seen this before)
Going back to two channels and no loop delay, i confirm do not see the "sink->stop send" debug message. (and get the two mixed sounds, but with the clicks again.)

Erich, could you compile my test ino and see if it works fully with an ESP32 with your modified library ?
many thanks all.
Dagnall

from hman-stomper.

@earlephilhower
@ErichHeinemann
Update, just swapped hardware and done some testing with I2s DAC.
Results may be instructive: (hopefully)
I'm getting speed changes depending on how many channels are active.
(Not sure if the sounds were playing Fast in the no dac tests, its a bit difficult to hear with the clicks.)
I also still seem to have the "loop delay induced" errors...

RESULTS:
2ch test, no delay in loop: sounds fine (no clicks) serial monitor shows wav progress
2ch test delay(1) in loop: No Audio, serial monitor does not show that new wavs are being played.
2ch test delay(100) in loop: As above
1ch test delay (10) in loop: Audio plays, but at 2X speed
1ch test delay (1) in loop: as above
1ch, no delay in loop: as above
3ch (no loop delay ) sounds seems to be playing slow (not half speed,?)
4ch (no loop delay) even slower. (Note to self: I should have had a test tone as one of the samples...)

I would surmise one issue in the noDAC for the clicks, plus another in the mixer for the channel related speed issues?

from hman-stomper.

Also, just discovered, the playback speed issue (DAC) is dependant on the ESP CPU frequency..

from hman-stomper.

from hman-stomper.

Erich, I used delay to simulate real issues that we will get when the main loop is fully populated. The code should be robust enough to stand a small delay in the main loop.
The delay(1) was outside the four if (wav2->isRunning() elements, which retain their yield() code, (which I think is redundant by the way)
Somewhere in Earles code he takes account of the actual ESP clock frequency, but I cannot see where, so cannot look for the equivalent bit in the mixer that may account for the mixer replay speed issue I found later.

from hman-stomper.

Actually, I don't take account the clock. The I2S is DMA controlled, and clocked at whatever fixed frequency is set up at the beginning of the run. So it "just works" assuming you feed the DMA engine samples before it underflows.

If you're getting clicks, it may be DMA underflows...on the ESP8266 it unfortunately doesn't export DMA underflow count so it's not easily trackable.

I only looked at it very early this AM before my flight, but I think that @ErichHeinemann 's code may only be processing a single sample per ->loop() call. If so, you may be spending too much time on overhead and get clicks. But, like I said, I'm not sure as this was just a few minutes before boarding.

If the sounds are coming out slow, it may be "silent" clicks where it sends a few samples, sends an underflow (0) buffer, then sends the next few samples, etc. Do that fast enough and the silent buffers can almost become unhearable while the sound seems to be slower than expected.

from hman-stomper.

Thanks for looking at the code.
I've done some more work "from the outside" and modified the way that the code starts /loops the samples. https://github.com/dagnall53/mixtest2
I have placed a set of timed "Begin" if's in the mainloop, simulating what would happen with my real code, where samples will be asynchronously triggered.
This seems to have removed (or at the very least changed) the click issue, which has mostly gone away.
But in doing this I have discovered that the Mixer does not properly start until it has all defined channels filled with samples. This is presumably not an issue with a beatbox, which is Erich's application, but for a more general mixer, it needs too cope with just one input even if defined for many more.
I can see that solving this may be a big problem!

from hman-stomper.

I have reinstated the set rate linkage from the AudioGenerator through to the Audio output, by modifying
bool AudioMixerInBuffer::SetRate(int hz) { return sink->SetRate( hz ); // to Ensure the linkages from AudioGenerator rate to the AudioOutput rate. // was originally return sink->SetMixRate( hz, channelNo ); }
This does not make a major change, but does allow use of different sample rate files. and takes account of the clock.. (providing all source files are the same of course)

However, during further exploring of the mixer, I have found that with a single channel, it seems to lose samples (about half of them?). I have updated my test code : https://github.com/dagnall53/mixtest2 to demonstrate that sending direct to the AudioOutput sounds fine, but sending it (as a single channel) via the mixer corrupts it.
I think that with Erich's application with repeating synth samples, this issue was not obvious. However when working with asynchronous AudioGenerator starts and with different numbers of channels being active, it is a problem.

I will try to track down the issue, but any assistance would be appreciated!

from hman-stomper.

@dagnall53 about the mixer not starting w/o samples from all inputs. That actually has to be by design. Whenever a new audiogenerator is triggered, the mixer should be able to add a new channel on the fly. When an audiogenerator ends, the mixer should be able to drop that channel too. So at any point in time, for all connections, you need samples from them all to advance.

I didn't realize Erich's code did resampling, that's great!

Since it looks like the BearSSL replacement is now working pretty stably I should have some spare time to look at this stuff over the weekend.

from hman-stomper.

As far as I an see, the AudioGenerator works with a 128 long buffer, but Erich's code, at least in the test example, only takes 8 samples into each channel buffer. It can take more (and I have used up to 255 as the buffer size) but the tests I did did not show any improvement on the issues I was exploring. I presume that the intent is that the multiple channels being added together to become the mix can only get 8 samples out of synch..
I agree that the code needs to accommodate channels switching on and off, and I think it does try, but if I can suggest, can you perhaps first find out why a single channel sent through the mixer gets corrupted? It may be that this is the main issue ? Certainly some mixing does take place, when there are more channels, but my current opinion/suggestion is that the most fruitful way forwards would be to get a single channel working perfectly.. My latest test code demonstrates this.

from hman-stomper.

Since I opened this year ago, I think all the noted issues have been resolved.
My latest tests have been with ESP32 and I still have some mute issues, but I think the ESP12 issue is done.
So I am closing it.

from hman-stomper.