Little endian...

[dagnall53]

@romaca made a comment in bbx10/SFX-I2S-web-trigger#3,
Where he suggests the following code will correct some issues: Unfortunately this looks very different in your ESP8266wavplay library code, so I was hoping you could add this shift to your "library" version please??

`Here's my play loop:-

#define SLC_BUF_LEN (64) // Use the same buffer size as DMA

int playWaveFile(wavFILE_t *wavFile,wavProperties_t props){
static uint8_t readBuffer[SLC_BUF_LEN2]; // DMA uses 32bits (only mono therefore 16 bits) / reads from SPIFFS in bytes
static uint16_t *p = (uint16_t *)readBuffer;
int count;

i2s_begin();
i2s_set_rate(props->sampleRate);
//Serial.println(props->sampleRate);
int bShiftIn= 0;
int bShiftOut = 0;

// Note: 8266 little endian - wav file little endian - should be good

while((count = wavRead(wavFile,readBuffer, SLC_BUF_LEN*2)) > 0) {
//Serial.print("Bytes transferred "); Serial.println(accumulated_count);
count >>=1;
for(p=(uint16_t *)readBuffer;count;count--,p++) {
// Shift output data 1 bit to the right to conform to I2S (non left justified) as
// hardware outputs data left justified.
bShiftOut = *p & 0x0001;
*p = (*p>>1 & 0x7fff) | (bShiftIn<<15);
bShiftIn = bShiftOut;
//Serial.println(String(*p,HEX));
i2s_write_lr(*p,p); //left channel data = right channel (mono) - blocks when full - DMA's in background
}
//Serial.print("");
yield();
}
i2s_end();`

[dagnall53]

I think this may be the correction as applied in your code:
Unfortunately, it does not seem to fully sort the noise issue, which may therefore be due to the LRC phasing...

bool ICACHE_FLASH_ATTR i2s_write_lr_nb(int16_t left, int16_t right){
int sampler = right & 0xFFFE; // was FFFF trying 1 bit right shift as per
// bbx10/SFX-I2S-web-trigger#3
int samplel= left & 0xFFFE;
sampler = sampler << 15; // bit shift left was 16, so this equates to one right
samplel = samplel >> 1; // right shift left channel
sampler |= samplel;
return i2s_write_sample_nb(sampler);
}
<

[romaca]

@dagnall53 Since I made this post I have determine that shifting, although may solve one of the problems, that patch is hiding a more fundamental bug imo. There should be no need to do this as I discovered after using Earle Philhower's recent library at https://github.com/earlephilhower/ESP8266Audio.git. This library seems to be an excellent library and includes the MAD MP3 decoder. If you want to continue with @techman83's code it maybe useful to eyeball the relevant parts of Earle's code to determine why it behaves differently. The code also btw has no issues with the clocks either.
Yes I did rewrite the play loop to ensure I understood what was happening and to make it as efficient loading the buffers as possible. After opening a wav file just call the playWaveFile(..) function from the loop() function. If you want to repeat the file you'll have to close then reopen the wave file. Also my shift routine treats the entire audio file as a long bitstream which gets shifted one bit to the right. I believe you're taking each sample from the left and right channel and shifting them which isn't the same, as you loose the MSB of sampler.

[dagnall53]

Huge thanks for taking the time to send me this. I agree that there seems to be something fundamental wrong at the heart of the code, I managed to get my code working reasonably well last night. I did a simple bit shift for each track, then put them together again, I see from your note that this was not what you intended, but if you did a whole message bit shift, wouldn't bits of one channel get shifted to the other? The code was working last night, but only by adding some serial.print("") in some loops. And I still got occasional rubbish sounds. This Seems crazy, but is presumably indicative of a deeper issue. FYI, my code is trying to make steam engine chuffs, so repeatedly calls a chuff.wav file, playing it at different speeds depending on the loco speed. It works reasonably convincingly for playback from 0.75 to 2 times the original (11k) sample rate. Strangely I also found Earle' GitHub last night and was planning on looking at it, your note encourages me to look more closely at his code, and I will probably base my code on his if I can get it working...looking deep in the c code to see what's different may be beyond my technical powers...I date back to BASIC, but did electronics, and c passed me by. Presumably I should probably also unedit the i2s library code mod?? ( perhaps that obscured the real bug in the techman code?) Cheers Dagnall

…

Sent from my iPad

On 15 Dec 2017, at 23:01, romaca ***@***.***> wrote: @dagnall53 Since I made this post I have determine that shifting, although may solve one of the problems, that patch is hiding a more fundamental bug imo. There should be no need to do this as I discovered after using Earle Philhower's recent library at https://github.com/earlephilhower/ESP8266Audio.git. This library seems to be an excellent library and includes the MAD MP3 decoder. If you want to continue with @techman83's code it maybe useful to eyeball the relevant parts of Earle's code to determine why it behaves differently. The code also btw has no issues with the clocks either. Yes I did rewrite the play loop to ensure I understood what was happening and to make it as efficient loading the buffers as possible. After opening a wav file just call the playWaveFile(..) function from the loop() function. If you want to repeat the file you'll have to close then reopen the wave file. Also my shift routine treats the entire audio file as a long bitstream which gets shifted one bit to the right. I believe you're taking each sample from the left and right channel and shifting them which isn't the same, as you loose the MSB of sampler. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[techman83]

Earle Philhower's library is far more fleshed out and thorough. I pretty much made some minimal changes to bbx10's code and made it behave like a library, but it needs much more work to be properly releasable. I'll update my readme's to point at that one, because I'll likely update my Doorbell to that as MP3 support would be super nice!

As for the crashing, I'm using the code as "released" and no changes to the ESP codebase. I did have issues with distortion, but using a proper power supply rather than USB solved that. Considering how loud it can drive the speaker I plugged into the dac I'm using, I'm entirely unsurprising.

Thanks for commenting @romaca!

[dagnall53]

I'm using Earles code now so thought this issue should be closed..

[techman83]

Awesome! Glad it worked out 🙂