philippe44 / squeezelite-esp32 Goto Github PK

oolchain path: /home/ole/.espressif/tools/xtensa-esp32-elf/esp-2020r3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: esp-2020r3
Compiler version: 8.4.0
Python requirements from /home/ole/esp/esp-idf/requirements.txt are satisfied.
Building partitions from /home/ole/esp/esp-idf/examples/squeezelite-esp32-master/partitions.csv...

App "squeezelite" version: v4.3-dev-2940-g6e776946d
CC build/cmd_system/cmd_system.o
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/components/cmd_system/cmd_system.c: In function 'light_sleep':
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/components/cmd_system/cmd_system.c:290:9: error: 'CONFIG_CONSOLE_UART_NUM' undeclared (first use in this function); did you mean 'CONFIG_ESP_CONSOLE_UART_NUM'?
if (CONFIG_CONSOLE_UART_NUM <= UART_NUM_1) {
^~~~~~~~~~~~~~~~~~~~~~~
CONFIG_ESP_CONSOLE_UART_NUM
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/components/cmd_system/cmd_system.c:290:9: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [/home/ole/esp/esp-idf/make/component_wrapper.mk:292: cmd_system.o] Error 1
make: *** [/home/ole/esp/esp-idf/make/project.mk:635: component-cmd_system-build] Error 2

Getting failure while making becouse make and project.mk not existing.

squeezelite-esp32-refactor-BT-I2C$ make defconfig Makefile:8: /make/project.mk: Datei oder Verzeichnis nicht gefunden make: *** Keine Regel, um „/make/project.mk“ zu erstellen. Schluss.
thanks

During waiting for an I2S dac, i wanted to try it with internal one.

Espressif said on
https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/i2s.html
you have to send NULL on i2s_set_pin(i2s_num, NULL) for enabling the internal dac
I changed the code:
in output_i2c addad on line 300 | I2S_MODE_DAC_BUILT_IN to configuration
changed line 313 to:
i2s_set_pin(CONFIG_I2S_NUM, NULL);//&pin_config); //chanched here for DAC output

But it isn't working.

The documentation says this whil configure dac to pin 25 & 26, but nothing happens.
Thanks for help.

In order to allow bundling of binaries for users not wanting to setup the build toolchain, we have to expose some parameters on the command line used to launch Squeezelite. They are:

• I2S Bit Clock GPIO number
• I2S Word Select GPIO number
• I2S Data I/O GPIO number

These require updating the output_i2s.c file to pass parameters from command line, as well as update the default command line to include an example. Command line parameters could be passed with encapsulation similar to what we do for bluetooth. For example:
squeezelite -o "I2S -ioClk 26 -ioWS 25 -ioDat 22" -b 500:2000 -R -u m -Z 192000 -r "44100-44100"
Parameter extraction example exists under bt_app_source.c, in function hal_bluetooth_init

Additionally, the following will have to be exposed:

• SPDIF I2S Bit Clock GPIO number
• SPDIF I2S Word Select GPIO number
• SPDIF I2S Data I/O GPIO number

Toolchain path: /home/ole/.espressif/tools/xtensa-esp32-elf/esp-2020r3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: esp-2020r3
Compiler version: 8.4.0
Python requirements from /home/ole/esp/esp-idf/requirements.txt are satisfied.

App "squeezelite" version: v4.3-dev-2940-g6e776946d
CC build/squeezelite/output_i2s.o
In file included from /home/ole/esp/esp-idf/examples/squeezelite-esp32-master/components/squeezelite/squeezelite.h:286,
from /home/ole/esp/esp-idf/examples/squeezelite-esp32-master/components/squeezelite/output_i2s.c:43:
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/components/squeezelite/embedded.h:41:46: error: unknown type name '_CONST'
int pthread_create_name(pthread_t *thread, _CONST pthread_attr_t *attr,
^~~~~~

Hi,

I installed sucessfully your project and it works immediatly with bluetooth soundbar, thats real great work!!

Pleas could you explain the advantage of resampling, how do i now which configuration is the best for me? Im using LG SK5 Soundbar

Whats the difference of Quality of BT, internal DAC and external DAC and is this differance noteable?

Thanks

Toolchain path: /home/ole/.espressif/tools/xtensa-esp32-elf/esp-2020r3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: esp-2020r3
Compiler version: 8.4.0
Python requirements from /home/ole/esp/esp-idf/requirements.txt are satisfied.

App "squeezelite" version: v4.3-dev-2940-g6e776946d
CC build/main/console.o
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/main/console.c: In function 'initialize_console':
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/main/console.c:186:2: warning: 'esp_vfs_dev_uart_set_rx_line_endings' is deprecated [-Wdeprecated-declarations]
esp_vfs_dev_uart_set_rx_line_endings(ESP_LINE_ENDINGS_CR);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/ole/esp/esp-idf/examples/squeezelite-esp32-master/main/console.c:16:
/home/ole/esp/esp-idf/components/vfs/include/esp_vfs_dev.h:45:6: note: declared here
void esp_vfs_dev_uart_set_rx_line_endings(esp_line_endings_t mode) attribute((deprecated));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/main/console.c:188:2: warning: 'esp_vfs_dev_uart_set_tx_line_endings' is deprecated [-Wdeprecated-declarations]
esp_vfs_dev_uart_set_tx_line_endings(ESP_LINE_ENDINGS_CRLF);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/ole/esp/esp-idf/examples/squeezelite-esp32-master/main/console.c:16:
/home/ole/esp/esp-idf/components/vfs/include/esp_vfs_dev.h:61:6: note: declared here
void esp_vfs_dev_uart_set_tx_line_endings(esp_line_endings_t mode) attribute((deprecated));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/main/console.c:194:4: error: 'CONFIG_CONSOLE_UART_BAUDRATE' undeclared (first use in this function); did you mean 'CONFIG_ESP_CONSOLE_UART_BAUDRATE'?
CONFIG_CONSOLE_UART_BAUDRATE, .data_bits = UART_DATA_8_BITS,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_ESP_CONSOLE_UART_BAUDRATE
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/main/console.c:194:4: note: each undeclared identifier is reported only once for each function it appears in
In file included from /home/ole/esp/esp-idf/components/esp_system/include/esp_system.h:20,
from /home/ole/esp/esp-idf/examples/squeezelite-esp32-master/main/console.c:13:
/home/ole/esp/esp-idf/examples/squeezelite-esp32-master/main/console.c:197:36: error: 'CONFIG_CONSOLE_UART_NUM' undeclared (first use in this function); did you mean 'CONFIG_ESP_CONSOLE_UART_NUM'?
ESP_ERROR_CHECK(uart_param_config(CONFIG_CONSOLE_UART_NUM, &uart_config));
^~~~~~~~~~~~~~~~~~~~~~~
/home/ole/esp/esp-idf/components/esp_common/include/esp_err.h:119:31: note: in definition of macro 'ESP_ERROR_CHECK'
esp_err_t __err_rc = (x);
^
make[1]: *** [/home/ole/esp/esp-idf/make/component_wrapper.mk:292: console.o] Error 1
make: *** [/home/ole/esp/esp-idf/make/project.mk:635: component-main-build] Error 2

Having the red and green LEDs is very useful - especially when getting things up and running for the first time.
Some changes could be useful though.
For example

• being able to disable the LEDs completely
• disable flashing of the green light when idling (can be useful when indicating error)
• error codes via different flash rates/patterns

Pull request #1 created for this.

Espressif has made littlevgl available of the platform.

https://github.com/espressif/esp-iot-solution/blob/master/documents/hmi_solution/littlevgl/littlevgl_guide_en.md

Leveraging Squeezelite's ring buffer

Basic authentication is going to be needed if we want to allow OTA updates and avoid unwanted software being injected. Here are some points to consider

• Default access point name is "squeezelite-9999" where 9999 is derived from the cpu's eFuse MAC
• Default user and password to something as simple as admin/admin-9999 where 9999 are the same letters as the ones for the access point name. This makes it easy to know what the password of the device is on the initial configuration
• During initial configuration, user must change the defaults before they can configure WiFi
• No need for multi user; this would add complexity and bring low value
• User need to change BOTH the user name and the password

A typical basic auth mechanism would work like this:

1. Upon boot, the ESP32 generates a token (e.g. a guid for example)
2. User name/passwords are passed to a new "/login" handler in the http server code
3. The handler checks the user name/password against a nvs variable
4. If user name/password validation is successful, the ESP32 sends the auth token back as a response through headers (no body needed) with something like "Cookie", "access_token=generated_token"
5. On every subsequent call, the http server validates the token against the known token
6. From there, an expiry mechanism should likely invalidate the token and generate a new one. For example, every time a request is made with a given token, an expiry counter resets. When a request is made and the token's expiry was reached, a new token is created and the client app goes back to the login screen.

Any improvement or suggestion is welcomed.

I am trying to install Squeezelite on a Lyriat board.
I think that the biggest problem is to handle the ES8388 chip (vs the AC101 on the SqueezeAmp board).
I think there would be 2 possibilties:

• to use the nvs parameter "dac_controlset" but I'm afraid it's very complex and difficult...
• to write a specific handler ((on the AC101 model) but in this case I will have difficulties in intoducing it in your squeezelite...
  What do you think about this ?
  Many thanks!...

(this is not an issue but a request for an advice!)

It would be possible to use this
https://github.com/PaulStoffregen/Teensy3-SPDIF

edit updated the link

I tried to Compile with "make flash" how described in the main Page and got following error:

`CC build/cmd_nvs/cmd_nvs.o
/home/martin/Schreibtisch/DEV/ESP/squeezelite-esp32-refactor-BT-I2C/components/cmd_nvs/./cmd_nvs.c:30:5: error: unknown type name 'nvs_type_t'
nvs_type_t type;
^

/home/martin/Schreibtisch/DEV/ESP/squeezelite-esp32-refactor-BT-I2C/components/cmd_nvs/./cmd_nvs.c:35:7: error: 'NVS_TYPE_I8' undeclared here (not in a function)
{ NVS_TYPE_I8, "i8" },
^

/home/martin/Schreibtisch/DEV/ESP/squeezelite-esp32-refactor-BT-I2C/components/cmd_nvs/./cmd_nvs.c:36:7: error: 'NVS_TYPE_U8' undeclared here (not in a function)
{ NVS_TYPE_U8, "u8" },
^

/home/martin/Schreibtisch/DEV/ESP/squeezelite-esp32-refactor-BT-I2C/components/cmd_nvs/./cmd_nvs.c:37:7: error: 'NVS_TYPE_U16' undeclared here (not in a function)
{ NVS_TYPE_U16, "u16" },

....
....
...

cc1: some warnings being treated as errors
/home/martin/esp/git/esp-idf/make/component_wrapper.mk:273: die Regel für Ziel „cmd_nvs.o“ scheiterte
make[1]: *** [cmd_nvs.o] Fehler 1
/home/martin/esp/git/esp-idf/make/project.mk:450: die Regel für Ziel „component-cmd_nvs-build“ scheiterte
make: *** [component-cmd_nvs-build] Fehler 2

`

I made the configuration with defaultconfig and in Menuconfig only changing the com port. Oter options are on default.

Hi,

How did you compiled the static libraries in squeezelite-esp32/components/codecs/lib/ ?

Could you share the steps you used ? I'd be happy to make a PR to create a README documentation about it.

Thanks you,

Yohann

Some of the amplifier / amplifier-chips, which can be used with squeezelite-ESP32 have a pin for mute / activation. It would be nice to be able to use this input to automatically switching the amplifier on / off when Squeezelite is playing or being activated. This could save some power and may reduce noise output on cheap solutions, when no output by squeezelite is produced.
Configure a GPIO pin (defining pin and also if high / low should be active).
There is already something similar for the raspberrypi version of squeezelite to control a relay:
" -G <Rpi GPIO#>:<H/L>\tSpecify the BCM GPIO# to use for Amp Power Relay and if the output should be Active High or Low\n"
Maybe this solution could be doubled and fitted to the ESP32.

Would it be possible to connect multiple Bluetooth devices or sending broadcasts?