No Audio output on ESP32_LyraT board

[pmumby]

Hi Jorgen, really appreciate the project. I've picked it up to try and get an inexpensive multi-room speaker build based on lyrat boards...

I've forked your code, and begun making it work on my board. I have a snapcast server, which I've tested to be working with an android client. I built the server with docker, and my server image can be found: https://hub.docker.com/r/pmumby/librespot-snapserver (including link to the github repo with code used to build it).

My current code (only a few minor modifications) can be found on my develop branch at: https://github.com/pmumby/snapclient/tree/develop

The code builds, and flashes fine. The board boots, joins the wifi, finds my snapcast server, and responds to volume control messages, etc... If I start streaming from spotify, it detects the chunks coming in, but no audio is seen on the headphone output (for now I'm working in the code with the bare board, no speakers on the amp output).

A bit of digging around indicated it might be the way the CODEC is initialized, so I fiddled with changing that code, but that didn't help. No audio at all out of headphones.

Next on my list is to source some speakers, and test it on the amp outputs, but won't be able to do that for a couple days. So thought I'd check with you to see if you have any suggestions, or if this issue affects you as well. Perhaps you can test using my server container to see if it's affecting you in the same way (ie: a symptom of my server, or config).

As I said it works fine with the android client, audio streams fine etc, and the lyrat board appears to be talking to the server fine... Just no audio output.

Any help greatly appreciated. Once the basic code is working to a known baseline state, I'll begin tackling some of the new features (wifi provisioning is next on my list, then some layer of user interface on the board itself)...

[jorgenkraghjakobsen]

Hi Mumby Thanks - I have not been able to spend time on this due to high work load on daytime job and other project (http://codingpirates.dk/in-english/) I have not worked with the headphone output on the Lyra board - I expect it requires some codec setup from esp - mixer setting, enable that output. I will have a look at the code / schematic to see if i can find something simple fix. I have the code working using the 2 amps on the board and external speakers. /Jørgen

[pmumby]

Hey Jorgen, name is Paul by the way :) Mumby is my family name.

Awesome, thanks for looking into it, I'm sure I'll figure it out eventually, but always helps to have someone who is familiar with the codebase already, and the hardware to a degree to help get it to a baseline known-good state.

For your convenience, here is the main change I made to the codec init, thinking perhaps the DSP output channels varied. I found this method referenced from another article trying to get the line input working for recording on the same board. https://github.com/pmumby/snapclient/blob/4107630cf1721a43e853a1c875bd498f74362df6/main/main.c#L645-L654

The interesting thing is since I've made this change, I notice that now I get hardware notices during monitoring on the console that show headphones inserted, and removed (so the headphone detection stuff has become active).

This method of initializing the codec is similar to what's used in the MP3 playback demo.

Anyway, thanks again for your help, I'll keep poking at it and hopefully get it working. Or I'll get some speakers to hook up to it, We'll see which comes first!

Also your other project seems to be an interesting one, and a good cause too!

Cheers!

• Paul

[jorgenkraghjakobsen]

Hi Paul - Sound good, will be cool to have all output enabled. I am back on the esp32 and audio track and working on bluetooth audio sink and some audio processing (BiAmp and bassboost) Hope that my focus can move to snapclient soon. /J

[pmumby]

Interesting note, I just did some digging on the ES8388, and the schematic, to see how the PAs and Headphones are wired up...

And it looks like they actually share a single output from the codec chip...

Looking at these excerpts from the schematic:

This shows the output L/R signal path from the DAC/Codec chip:

And the headphone jack itself:

And finally the PA interface: EDIT: Missed the point where DAC_ROUT and DAC_LOUT signals are coupled to the PA_IN signals... Corrected with second image

You can see from that, that the headphone talks to GPIO for detection, but it's using the internal switching in the typical way to bypass the LOUT1 and ROUT1 (positive side) input to the PA chips...

That implies that the PA is using the exact same analog output lines as the headphones... So if you have audio on one, it should be on both (provided IO21 is enabling the PAs)...

So handy that my init method gives headphone detection, but apparently that has nothing to do with enabling the headphones... Which leads me to believe, that I have another problem (no audio output at all) and it's not just specific to the headphone jack.

Might be the audio stream I'm sending, because it's coming from spotify possibly... (transcoding of some kind going on in the snapserver)... As I said I'm getting audio fine out of the android snapclient... So the server is working, and it's sending opus format data which contains audio, but maybe something is odd about it that is making the board choke... I'm not getting any errors in the console, just sees chunks coming in... But I do note an odd behavior, when I hit stop in spotify, the chunks stop, and a second later, the ESP crashes and reboots, with the following:

I (148566) I2S: Chunk :960 30272 29055
I (148566) I2S: Chunk :960 29312 29051
I (148576) I2S: Chunk :960 28352 29047
I (148586) I2S: Chunk :960 27392 29013
Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x400d6b5f  PS      : 0x00060530  A0      : 0x80088b28  A1      : 0x3ffe7080
0x400d6b5f: dsp_i2s_task_handler at x:\esp\snapclient\build/../components/dsp_processor/dsp_processor.c:170 (discriminator 1)

A2      : 0x00000000  A3      : 0x00002eb4  A4      : 0x000000f0  A5      : 0x00000000
A6      : 0x00000000  A7      : 0x0002446a  A8      : 0x00000000  A9      : 0x3ffe7060
A10     : 0x00003a34  A11     : 0x3ffb0cac  A12     : 0x3ffd4650  A13     : 0x3fff00a0
A14     : 0x00000000  A15     : 0x3fff0098  SAR     : 0x00000003  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000  LBEG    : 0x4000c28c  LEND    : 0x4000c296  LCOUNT  : 0x00000000

ELF file SHA256: a5120870c09d2c7e

Backtrace: 0x400d6b5c:0x3ffe7080 0x40088b25:0x3fff02e0
0x400d6b5c: dsp_i2s_task_handler at x:\esp\snapclient\build/../components/dsp_processor/dsp_processor.c:170 (discriminator 1)

0x40088b25: vPortTaskWrapper at X:/esp/esp-idf/components/freertos/port.c:143

So perhaps there is something odd going on...

I'll try to test using a simpler source similar to your instructions to see if that works...

[pmumby]

Just found this in the documentation: https://docs.espressif.com/projects/esp-adf/en/latest/design-guide/board-esp32-lyrat-v4.3.html#selecting-of-the-audio-output

Which seems to indicate that you need to toggle IO21 to switch between PA and Headphones, based on input from IO19 (headphone detect)...

That said, I don't see in the schematic how that makes any sense... I don't see IO21 or IO19 linking back to the DAC chip anywhere, so from what I can see, the headphones should output no matter what, and the speakers should output if IO21 is active. And as per my previous post, it looks on the surface like the jack disables the positive path audio signal anyway to the PAs... So this section of the documentation is a bit confusing.

Either way I'll have a go at toggling that IO in software on the headphone detect signal. And I'm also hopefully going to snag a couple 4ohm speakers to hook up to it later today. So one way or another I hopefully will get to the bottom of it.

[pmumby]

Just as a quick update on this, I've tested now with speakers wired to the PA outputs, and still no audio... So something else is clearly wrong. Haven't yet done another simpler test with your test setup for a source... Will try that next as I have time.

Thanks!

[pmumby]

Updated the title to reflect that this appears to be no audio at all.

I've tested using your test with mplayer to the pipe, using the same pipe config you use in your sample... And I again get audio on Android client, but no audio at all via headphones or speakers on the LyraT board.

I did notice when starting the stream I get this briefly in the monitor console, (I haven't noticed this before):

E (13396) I2C_BUS: X:/esp/esp-adf/components/esp_peripherals/driver/i2c_bus/i2c_bus.c:101 (i2c_bus_write_bytes):I2C Bus WriteReg Error
I (13406) SNAPCAST: Received codec header message

I (13406) SNAPCAST: Codec : opus , Size: 12

I (13406) SNAPCAST: Opus sampleformat: 48000:16:2

I (13406) SNAPCAST: Initialized opus Decoder: 0
I (13416) SNAPCAST: OPUS encoding buffer too small, resizing to 120 samples per channel
I (13426) SNAPCAST: OPUS encoding buffer too small, resizing to 240 samples per channel
I (13436) SNAPCAST: OPUS encoding buffer too small, resizing to 480 samples per channel
I (13446) SNAPCAST: OPUS encoding buffer too small, resizing to 960 samples per channel
I (14376) I2S: Chunk :960 31040 28863
I (14376) I2S: Chunk :960 30080 28889

So I'll take a look into that, to see if that I2C WriteReg error may be related. I'll also double-check the dip switch settings on the board, or anything else that may be causing my board to behave differently than others.

Edit: I should also note, that when the stream begins, and the chunks are flying by on the monitor, I can hear the amp engage on the headphones, and when it ends I can hear it end (there is a very subtle pop, and a change in the background noise on the headphones while the stream is active to when it's not active), so it's doing something...

Anyway, will keep investigating.

[jorgenkraghjakobsen]

Hi Paul Sorry for my late response - I took some time last night and also find my code / esp-idf/adf quite broken. Also found the code to be very hard to deal with as it more prove of concept then a working solution. I fixed my setup - rolled back to IDF 4.1 ADF 1.1 - and found root course due to esp32 to codec i2s hook up - that apparently also step on one of the i2c lines, coursing the I2C WriteReg error you also noted - I will commit what I have now - and try to map out a plan to clean up the code. I need to split the various function blocks by 5 and have a one stop menuconfig to adapt hardware by choice. Regards Jørgen

[pmumby]

Hey Jorgen, thanks! That's an awesome find. Would have taken me a while to dig down to that root cause.

Once I've got my head into the code, and have a working baseline, I can certainly help with a refactoring/cleanup of the code.

We could start a "cleanup" branch if that makes sense, to work against until it's caught up to the baseline capability of the current-state.

I'll take a look at your newly committed code, and test on my end, to confirm if it fixes the problem.

Cheers!

Paul

[pmumby]

Hey, sorry for the delay, things got insanely busy at work. I can confirm the no-audio issue is fixed with this commit. I've merged it back into my fork, and am working from there.

I still have some oddities, but I'm pretty sure are entirely unrelated. So I'll raise that with you separately.

Closing this ticket, as the issue is resolved.

Thanks!