ANNOUNCE: Squeezelite-ESP32 (dedicated thread)

[philippe_44]

I apologize if this is a rudimentary question, this is definitely the hard-core corner of the LMS frontier.

I have set up an Mn Cast Raspiaudio box. As warned in this thread repeatedly, the ESP32 gets overwhelmed with high bitrate FLAC - I'm getting stuttering on 24/96k files. So far, no problem, I understand.

But I've been assuming it was possible to force transcoding on my very-capable LMS server somehow. I figured I could set some kind of per-player threshold or limit for the ESP32 that the LMS server would honor, and the LMS server would resample everything on the fly before sending it to the EMS32. If this is possible, I can't figure out how to do it.

I'm not bitrate obsessed - I have no illusions that I can hear the differences between high bitrate and redbook audio. I'm content with some dither error or whatever when streaming to ESP32. But I do purchase high bitrate files when the cost differential isn't crazy, so I have a fair amount of them, and will continue to buy them..

Suggestions?

It is really overwhelmed if you use the 32 bits version under not very good WiFi conditions and potentially use SPDIF. Now, you can limit the esp32 bitrate and force LMS to do transcoding by using the "-Z 48000" option of the squeezelite/esp32 command line that will force squeezeesp32 to indicate a capacity of just 48k to LMS

[CJS]

But I've been assuming it was possible to force transcoding on my very-capable LMS server somehow. I figured I could set some kind of per-player threshold or limit for the ESP32 that the LMS server would honor, and the LMS server would resample everything on the fly before sending it to the EMS32. If this is possible, I can't figure out how to do it.

What Philippe mentions limits the sample rate of the audio sent to the player to 48000 samples per second. You can also limit the bitrate of the audio sent to the player via the LMS web interface. On the Player tab, select the player for which you want to limit the bitrate, and then Audio. Under the Audio settings there is a setting called Bitrate Limiting. If you change this setting from No Limit to for example 320kbps, LMS will transcode FLAC files to 320kbps MP3 files. See screenshot below.

[Stumphy]

What Philippe mentions limits the sample rate of the audio sent to the player to 48000 samples per second. You can also limit the bitrate of the audio sent to the player via the LMS web interface. On the Player tab, select the player for which you want to limit the bitrate, and then Audio. Under the Audio settings there is a setting called Bitrate Limiting. If you change this setting from No Limit to for example 320kbps, LMS will transcode FLAC files to 320kbps MP3 files. See screenshot below.

Yeah, I haven't streamed MP3 if I had a choice since the SliMP3. Thank you though!

It is really overwhelmed if you use the 32 bits version under not very good WiFi conditions and potentially use SPDIF. Now, you can limit the esp32 bitrate and force LMS to do transcoding by using the "-Z 48000" option of the squeezelite/esp32 command line that will force squeezeesp32 to indicate a capacity of just 48k to LMS

Ah, ok! I was wondering if that was the right option. This is working much better now. Thank you as well!

I have one more issue, I'll put it in the next message.

[Stumphy]

I'm getting a fairly consistent dropout at the end of tracks. The silence lasts maybe 0.5 seconds, and comes about 8 seconds before the end of a track. If I rewind it will often recur at about the same place, but not every time. The first time playing every track, it happens pretty reliably - at least 90% of the time.

This is an Mn Cast, running SPDIF, now limited to 48k on FLAC tracks, and I have the display working as well. Is this a known issue? Is there something I can do about it?

This was happening before I added the 48k limit by the way, and happens on all FLAC tracks regardless of original bitrate.

Again, I understand this is a minor miracle that it is working at all on such a cheap chip. Just hoping I can get the keel to clear the harbor.

[AngloCuencano]

I'm getting a fairly consistent dropout at the end of tracks. The silence lasts maybe 0.5 seconds, and comes about 8 seconds before the end of a track. If I rewind it will often recur at about the same place, but not every time. The first time playing every track, it happens pretty reliably - at least 90% of the time.

This is an Mn Cast, running SPDIF, now limited to 48k on FLAC tracks, and I have the display working as well. Is this a known issue? Is there something I can do about it?

This was happening before I added the 48k limit by the way, and happens on all FLAC tracks regardless of original bitrate.

Again, I understand this is a minor miracle that it is working at all on such a cheap chip. Just hoping I can get the keel to clear the harbor.

I have a similar problem. For me the dropout occurs 10 s before the end of the track, but not for all tracks. I think the dropout coincides with a burst of data from LMS to buffer the upcoming track. My "feeling" is that whether or not a dropout occurs is related to the bitrates of the playing track and the next track. When the combined data rates exceed some limit, then the dropout occurs. But I have to admit I have not put in the effort to prove it.

The suggestion by CJS to turn on LMS bitrate limiting does prevent the dropout, but it adversely affects gapless play, which is a bigger problem to my ears.

I have decided just to live with the occasional brief dropout.

[sle118]

SqueezeIO?!? That sounds interesting
Can we follow that project?

Soon

[sle118]

I have a similar problem. For me the dropout occurs 10 s before the end of the track, but not for all tracks. I think the dropout coincides with a burst of data from LMS to buffer the upcoming track. My "feeling" is that whether or not a dropout occurs is related to the bitrates of the playing track and the next track. When the combined data rates exceed some limit, then the dropout occurs. But I have to admit I have not put in the effort to prove it.

The suggestion by CJS to turn on LMS bitrate limiting does prevent the dropout, but it adversely affects gapless play, which is a bigger problem to my ears.

I have decided just to live with the occasional brief dropout.

are you streaming local content, or?

[AngloCuencano]

are you streaming local content, or?

Yes, mostly flac files, and mainly 44.1 KHz. I changed to proxied streaming, and that made the glitching less noticeable. I have no problems with streaming content.

[philippe_44]

Yes, mostly flac files, and mainly 44.1 KHz. I changed to proxied streaming, and that made the glitching less noticeable. I have no problems with streaming content.

Do you use the 32 bits version and/or spdif output?

[AngloCuencano]

Do you use the 32 bits version and/or spdif output?

No, I use 16 bits and I2S.

Since this problem got into my head again, I played around a bit with the buffer settings. If I put -b 700:1800, then the dropout seems to be eliminated. But I have not listened very extensively since I made this change.

[moopmm190]

Hi, my board is getting boot loop whenever it exits recovery mode, with every version I tried, latest or dated, and even raspiaudio's causes immediate boot loop.
I tried to not setup at all and exit recovery, tried setup preset or SPDIF, all leads to this boot loop:

[00:01:41.880301] output_init_common:361 unable to malloc output buffer

assert failed: 0x400d560e

Backtrace:0x40081a9d:0x3f807490 0x40097c45:0x3f8074b0 0x4009c2e5:0x3f8074d0 0x400d560e:0x3f807510 0x400decdc:0x3f807530 0x400def36:0x3f807610 0x400de370:0x3f807650 0x400eeca4:0x3f807980

I'm using ESP32-CAM board which suppose to have 4MB PSRAM, I've tried sample camera web server sketch to verify the board is indeed working.




Any help would be appreciated as I'm really interested into this audio solution, thanks.

[sle118]

Hi, my board is getting boot loop whenever it exits recovery mode, with every version I tried, latest or dated, and even raspiaudio's causes immediate boot loop.
I tried to not setup at all and exit recovery, tried setup preset or SPDIF, all leads to this boot loop:



I'm using ESP32-CAM board which suppose to have 4MB PSRAM, I've tried sample camera web server sketch to verify the board is indeed working.




Any help would be appreciated as I'm really interested into this audio solution, thanks.

I'm going to start with the read me:

https://github.com/sle118/squeezelite-esp32#what-is-this

We're calling out the wrover chip here because it's proven to work.

As for your problem, it could be that your ESP32 module uses a spi RAM chip that isn't supported by the version of esp-idf we're building against. Since I don't have that module, I can't help much. Perhaps someone in the forum tried a similar module before?

It is very likely that this type of memory is only supported in a version of the build environment that we don't support at the moment.

[Wiredcharlie]

Is it possible to switch a GPIO on the ESP32 using http?

Are you able to do an http post of a json payload from that plugin? if so, I could probably add a small console command. It would register under the "advanced" tab that shows up when you enable it from the credits tab.

I figured out a way to make this work for me if you add the command as suggested. Much appreciated.

[sle118]

I figured out a way to make this work for me if you add the command as suggested. Much appreciated.

Please create an issue in GitHub so I can keep this on the radar. It is relatively low effort, so I think I can make that happen

[pstevens]

I had a lot of trouble making a very similar board work. The key to the solution is to follow the official advice to put a 1uF capacitor between the 'en' pin and ground. This will ensure that the board resets correctly on power up.

Long description:

My board reports:

Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz

i.e not not the expected model for a module marked WROVER-E

Built the software from git and flashed over USB. Same problem with boot cycles.

Building software with 40MHz SPI for ROM and RAM works as described but is not fast enough to play without glitches.

I then built the main app at 80Mhz and just loaded this. This did work but would not survive a power cycle.

After adding the capacitor external to the baord (I used .47uf as I had nothing else suitable, smaller values do NOT work. I strongly recommend using 1uF) The board worked perfectly.

I deduce the the board is powering up in an inconsistent state, Not too surprising!

AS it now works I have not tried the full re-flash at 80Mhz , but have little doubt that it would work.

This ESP module does bring out the ROM SPI signals to the external pins on my board. Verified with a scope. I have removed the 6 relevant pins from the connector.

(See previous posts for details and pictures) Not sure that this is strictly necessary but if your board has them, then
you really do not want anything connected to them when using 80Mhz !


Best of luck. and I would like to hear any comments.