RASPIAUDIO / squeezelite-MuseLuxe

2 stars 0 forks source link

re-integrate in squeezeesp32 (not really and issue but discussions are not open) #2

Open philippe44 opened 2 years ago

philippe44 commented 2 years ago

I had a look at the changes

RASPIAUDIO commented 2 years ago

Bonjour Philippe ! 1-- We already talked about this on your site a long time ago (KheperV3)

2-- Yes, the buttons are indeed created by an NVS variable... 3-- For the battery, we must of course read the value... but we have to link a conditional action (here the color of the Neopixel LED)... 4-- RMT sends the serial signal that turns on the Neopixel(s)

Thanks Philippe !

On va y arriver !

Louis

philippe44 commented 2 years ago

Hi Louis

1- So it should be fine now b/c the MCLK as an option is also built-in 2- We should see if/how you want that to be integrated. My recommendation is a lock with a special build and so the possibility to have exactly the same through NVS in the I2S build. This is how SqueezeAMP works 3- I might be able to have the built-in code do the averaging. It depends exactly how you want to do it, but today there is already some flexibility - it takes one measure every 10s, scales it and then every 30 counts calls a handler. The idea is that there is a callback void (*battery_handler_svc)(float value) in monitor.h. Just set it with what you want, play nice, meaning that if it is not NULL, chain it. Of course, ultimately that callback is dedicated code, but it can be minimized and identified in a dedicated place 4- so same as 3-

RASPIAUDIO commented 2 years ago

Hi Philippe, So if I understand correctly, the best is to treat it like SqueezeAmp with a specific menuconfig. I agree and I can try to work on it...

In addition - but this is secondary - there are 2 features of Muse that we could try to integrate:

philippe44 commented 2 years ago

I can take care of the menuconfig and submit a PR, what we'd need to discuss is the rest and maybe how you want the battery calculation to be done. Maybe we can discuss that on gitter

schmurtzm commented 2 years ago

Hi, I'm also interested into the way to use codecs of Squeezelite-ESP32 in another way than lms only. The idea is to keep the squeezelite capabilities but have a more versatile/autonomous player which doesn't necessarily requires lms server to be usable. Read from SD card or USB is an idea, I've also in mind to be able to control the player to read online streams ordered by MQTT (or any other protocol like a web api).

philippe44 commented 2 years ago

If you look at the latest commit of the cmake version, I've integrated most of Muse components. There is a targets/muse/muse.c file that you need to tweak to your needs, but other than that it seems to work. One thing on my muse is that volume is very low

schmurtzm commented 2 years ago

You just ensured the future firmware updates on the long term 😄 , thanks for the benevolence on the children projects

RASPIAUDIO commented 2 years ago

I start to try to use the "driver" es8388 3 questions/comments: 1- where to put the initialization of MCLK (it's 2 very specific lines)?

2- There is no "volume" sequence in the es8388 driver... I think it's important... because otherwise the adjustment is made by weakening the source... right?

3- I don't see how ".../targets/muse/muse.c" is related to the rest of the processing

RASPIAUDIO commented 2 years ago

...for 1: create an nvs variable "init_MCLK" = 0(default) or 1 ? ...for 2 : add the sequence with .json format or not ?

philippe44 commented 2 years ago

Look at my latest commitments on the cmake version, I've set it up by using the i2s basic driver and adding all your init sequence. You don't have to do anything in muse.c now

philippe44 commented 2 years ago

I've "finalized" the updates so now, if that works for you, you should just set adapt the battery logic to your needs. What I don't know is:

[edit]: I've also updated version 4.3 and it works in muse as well (spotify)

schmurtzm commented 2 years ago

I've "finalized" the updates so now, if that works for you, you should just set adapt the battery logic to your needs. What I don't know is:

* how many cells are there
* what is the scale factor for a 100% charged battery (on SqueezeAMP there is a divider to maximize ADC range)

Hi, I don't know how many cells there are but there's some common code about batteries in examples : https://github.com/RASPIAUDIO/museProto_radio/blob/4a842f76e6887097a7d916053f73decbfd529404/museProto_radio/museProto_radio.ino#L128

[edit]: I've also updated version 4.3 and it works in muse as well (spotify)

what do you mean by "spotify" ? Spotify Connect ?

philippe44 commented 2 years ago

Yes, I mean Spotify connect

schmurtzm commented 2 years ago

cspot integration !? Awesome ! I wasn't expecting it, I saw an old issue last days which seems compromising it. Just tested on my ESP32, seems to works fine. An awesome additional point for the ESPMuse Luxe too. By the way @RASPIAUDIO on the main page of the website :

ESP32 programmable to be able to:
Airplay, Bluetooth, Logitech media server, SD card mp3 play

You could add spotify connect now and I think you should write "Squeezebox" instead of lms, philippe44 and sle118 are making exploits on ESP but I don't think that we will see a lms server on ESP one day :p

philippe44 commented 2 years ago

2- There is no "volume" sequence in the es8388 driver... I think it's important... because otherwise the adjustment is made by weakening the source... right?

On that topic, I've opted for just software volume in general. At the end of the day and in your configuration, you're driving a fixed-gain power amplifier, so all we do is reducing the DAC output excursion. Whether you do that using a real analogue divider or in the digital domain has very limited impact on perceived sound.

Don't get me wrong, I'm not trying to be argumentative and if you prefer to absolutely use what ES8388 calls DAC volume (I'd be curious to know what's really inside), of course please do but then that will be a fork of squeezelite-esp32. Having soft gain is important here as it ensures consistency of VU and spectrum (I did not say precision but just consistency :smile:)

RASPIAUDIO commented 2 years ago

I'm running out of time today and I'll email you a full answer tonight...

It works well... but there are several unresolved points (by me anyway)

For the battery and the led (neopixel) I will detail that later...

Thank you for everything Philippe

schmurtzm commented 2 years ago

Hi, I've just receive my Muse Luxe, I've been surprised to find a simple Bluetooth firmware on it so I've flashed it with Squeezeesp32 quickly. For now to avoid to set everything by hand I've flashed with the bin from this repo and then updated to 4.3 but doesn't seems to work as expected (probably something to change on the DAC config, if you have a good nvs file for 4.3 I'm interested).

@philippe44 "Preset Options" is a very welcome option ! Looking forward finding the Muse Luxe inside.

For information the sound with the firmware from this repo is loud.

I have some observations and remarks about the Muse, I will probably make a post about these on the forum. Do not hesitate if I can help for some tests.

philippe44 commented 2 years ago

@schmurtzm if you want my build to work, you have to flash everything, not just the squeezelite.bin - you can use "idf.py flash" to do that or if you just have the flash tools, go to LMS forum and find the list and addresses of binaries to update with the GUI downloader

philippe44 commented 2 years ago

I'm running out of time today and I'll email you a full answer tonight...

It works well... but there are several unresolved points (by me anyway)

  • there is an error in the "BUILD": i2s.c line 883

  • the sound is very low

  • buttons are not taken into account

(I have ideas on these 3 points)

For the battery and the led (neopixel) I will detail that later...

Thank you for everything Philippe

Strange that buttons don't work, what idf version have you chosen? Sound is low, I agree and I was hoping you could tell me why. Wrt i2s.c, it should compile so we may really have different build environment.

schmurtzm commented 2 years ago

@schmurtzm if you want my build to work, you have to flash everything, not just the squeezelite.bin - you can use "idf.py flash" to do that or if you just have the flash tools, go to LMS forum and find the list and addresses of binaries to update with the GUI downloader

Yes that's what I've done with binaries from here : esptool.exe --baud 921600 write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x1000 bootloader/bootloader.bin 0x8000 partition_table\partition-table.bin 0xd000 ota_data_initial.bin 0x10000 recovery.bin 0x150000 squeezelite.bin

I think that the problem is more about my I2S configuration after flashing (because it works with the older firmware)

philippe44 commented 2 years ago

I'll share a build later today because for now, you have to rebuild everything using a dedicated target or you need the new squeezelite generic i2s build that has not been released yet (look at artefacts of actions on GH) and use some specific nvs parameters (see main/Kconfig.projbuild) and look for everything with an "if MUSE" flag, it is mainly dac_config, dac_controller and bat_config.

schmurtzm commented 2 years ago

main/Kconfig.projbuild , good to know ! OK, my config file is ready for Muse, now waiting for the new I2S build. Thanks for your support ! (I have to start learn to build this project but I'm a little afraid by codec compilation 😅 )

philippe44 commented 2 years ago

Re codecs, the best is to just use the pre-build ones I'm offering. I never rebuild them, they are not part of the build chain

philippe44 commented 2 years ago

Here is my 4.3 build Muse.zip

philippe44 commented 2 years ago

I've also added Muse config script in 4.0 and 4.3 so that what I do is more clear

RASPIAUDIO commented 2 years ago

Hi Philippe, did you read my e-mail ?

schmurtzm commented 2 years ago

Here is my 4.3 build Muse.zip

Thank you Philippe, my Muse is currently in 4.3 and working fine (squeezelite,airplay and spotify quickly tested). Now I have a packaged device to make serious tests, thanks both for that ! I didn't found "Preset Options" in your firmware but I presume it is normal because it is a custom firmware.

I think that the sound seems less loud than with Raspiaudio firmware so I presume that the ES8388 is not driven exactly in the same way.

philippe44 commented 2 years ago

Hi Philippe, did you read my e-mail ?

No I did not, let me check my spam

philippe44 commented 2 years ago

Here is my 4.3 build Muse.zip

Thank you Philippe, my Muse is currently in 4.3 and working fine (squeezelite,airplay and spotify quickly tested). Now I have a packaged device to make serious tests, thanks both for that ! I didn't found "Preset Options" in your firmware but I presume it is normal because it is a custom firmware.

I think that the sound seems less loud than with Raspiaudio firmware so I presume that the ES8388 is not driven exactly in the same way.

The preset will come later, that's @sle118's realm. I have that same problem of the speaker being to quiet but I've not beena ble to figure out why. Hence I need to talk to @RASPIAUDIO. It's the same dac_controlset

[edit]: was a silly mistake - figured out now

RASPIAUDIO commented 2 years ago

OK, I'm posting the message not received here. (it is encrypted in French!!!) Maybe it would be better to talk about all this face to face... what do you think?


Donc, voilà où j'en suis:

Sur la version chargée ce matin, je constate :

J'ai essayé de comprendre ce dernier point en supposant que l'essentiel est dans dac_external.c

2 remarques :

1- la validation de MCLK y est bien. Mais il manque l'enable de l'ampli (par le GPIO 21)

la séquence est la suivante (elle est dans muse.c) :

define PA GPIO_NUM_21

            gpio_reset_pin(PA);
            gpio_set_direction(PA, GPIO_MODE_OUTPUT);
            gpio_set_level(PA, 1);   

à moins qu'elle ne se trouve ailleurs....

C'est d'ailleurs bizarre que cela marche un peu sans ça...

2- Et aussi, Dans cette séquence tu cherches le mot clé "model" dans CONFIG_DAC_CONTROLSET où il ne peut être...

Je crois que ça devrait être dans CONFIG_DAC_CONFIG

Je peux me tromper!!! sois indulgent !!!

D'ailleurs, je pense que même si les 2 points + haut sont vrais , il y a autre chose qui ne va pas....

Je continue à travailler sur cette intégration....

Amitiés.

Louis

philippe44 commented 2 years ago

Regarde la version que j'ai mise à jour tout à l'heure (cmake or cmake.43). Il faut soit utiliser le fichier Muse-sdkconfig.defaults comme config ou faire un idf.py menuconfig et choisir "muse" comme target. Tout devrait builder et plus de problème de volume ou de buttons. La seule chose qui reste à faire c'est la batterie et les led à base de rmt. L'es8388, le pa, la majeure partie du sampling de la batterie sont faits. Tout est configuré dans le menuconfig ou dans le preset Muse-sdkconfig.default. Tu peux aussi utiliser les artifacts du dernier build. Attention, il faut tout charger, bootloader, recovery, etc...

RASPIAUDIO commented 2 years ago

On the version I just downloaded the sound is loud and good but the buttons are still not taken into account... (I continued my research... yesterday I was wrong on some points: MCLK ==> adac_core.c keyword mclk enable amp ==> output_i2s.c i think isn't it? )

RASPIAUDIO commented 2 years ago

oui j'ai fait comme tu dis... Le son est changé du tout au tout Mais les boutons toujours pas Il a aussi l'erreur de build sur i2s.c => adc_power_always_on() pas reconnu que je dois remplacer par adc_power_on() C'est du je pense à un pb entre 4.0 et 4.1

RASPIAUDIO commented 2 years ago

oui je fais toujours un "build all"

RASPIAUDIO commented 2 years ago

Buttons work if I add this in "register_default_nvs()"

    char boutons[450];
    strcpy(boutons, CONFIG_AUDIO_CONTROLS);
    store_nvs_value(NVS_TYPE_STR, "boutons", boutons);
    config_set_default(NVS_TYPE_STR, "actrls_config", "boutons", 0);
store_nvs_value(NVS_TYPE_STR,"actrls_config", "boutons");

I hope this helps !

philippe44 commented 2 years ago

On the version I just downloaded the sound is loud and good

but the buttons are still not taken into account...

(I continued my research... yesterday I was wrong on some points:

MCLK ==> adac_core.c keyword mclk

enable amp ==> output_i2s.c i think

isn't it?

)

Yes, this is where these are set to all codecs or targets that need these

philippe44 commented 2 years ago

oui j'ai fait comme tu dis...

Le son est changé du tout au tout

Mais les boutons toujours pas

Il a aussi l'erreur de build sur i2s.c => adc_power_always_on() pas reconnu que je dois remplacer par adc_power_on()

C'est du je pense à un pb entre 4.0 et 4.1

Vous êtes sur une 4.1 ? Je ne recommande pas. On supporte deux idf 4.0 et 4.3 mais 4.1 c'est s'exposer à des ennuis. On devrait arrêter bientôt la 4.0 de toutes façons.

philippe44 commented 2 years ago

Buttons work if I add this in "register_default_nvs()"

    char boutons[450];
    strcpy(boutons, CONFIG_AUDIO_CONTROLS);
    store_nvs_value(NVS_TYPE_STR, "boutons", boutons);
    config_set_default(NVS_TYPE_STR, "actrls_config", "boutons", 0);
store_nvs_value(NVS_TYPE_STR,"actrls_config", "boutons");

I hope this helps !

Tu as raison, j'avais oublie de porter une modification qui utiliser la configuration statique des audio controls de 4.0 vers 4.3

RASPIAUDIO commented 2 years ago

OK Super! Pour la batterie, je ne suis pas plus avancé que ce que tu as pu voir dans muse.c : 1- la mesure acquisition périodique ( T= 1sec ou + 5 voire 10sec) moyenne N mesures (10 par exemple) (la valeur brute obtenue < 4095 par principe, 2300 ici pour la batterie à pleine charge) 2- l'action C'est allumer la led neopixel en vert jaune ou rouge suivant la moyenne brute obtenue comparée à 2 seuils (VGREEN et VRED) Ces valeurs ne sont très faciles à déterminer En général, c'est une opération qui n'appelle pas une grande précision je pense...

Je vais passer à la version 4.3 dès demain ou lundi (comme ce n'est pas la version par défaut, il faut passer par le .zip?)

philippe44 commented 2 years ago

OK Super!

Pour la batterie, je ne suis pas plus avancé que ce que tu as pu voir dans muse.c :

1- la mesure

acquisition périodique ( T= 1sec ou + 5 voire 10sec)

moyenne N mesures (10 par exemple)

(la valeur brute obtenue < 4095 par principe, 2300 ici pour la batterie à pleine charge)

2- l'action

C'est allumer la led neopixel en vert jaune ou rouge suivant la moyenne brute obtenue comparée à 2 seuils (VGREEN et VRED)

Ces valeurs ne sont très faciles à déterminer

En général, c'est une opération qui n'appelle pas une grande précision je pense...

Je vais passer à la version 4.3 dès demain ou lundi (comme ce n'est pas la version par défaut, il faut passer par le .zip?)

Par défaut, le système build-in fait une mesure toutes les 10s et fait un appel de la callback toutes 5 mins. Mais la valeur retournée dépend d'un scaling factor: lecteurs de l'ADC, multipliée par scaling factor pour normaliser en volts 0. Ensuite, le nombre cellules de LiIon permet de laisser le core faire une évaluation pour la webUI. Donc la question est : quel scaling pour avoir Volts = adc scaling / 4095. Sachant que vous utiliser une valeur d'atténuation adc esp32 qui est prise en compte dans bat_config, donc scaling est juste vraiment le facteur multiplicateur pour avoir des volts à partir de la lecture de l'adc. Si 2300 est votre max et que vous avez une cellule à 4.2, alors scaling = 4.24095/2300=7.48 Mais je ne sais pas si vous avez 1, 2 ou 3 cells et si vous souhaitez le max a 4.2, 4.3 ou 4.4

Ensuite, vous pouvez avoir votre propre solution pour transformer ces volts en N niveaux

Je ne suis pas sûr de bien comprendre la question sur 4.3. Il faut juste faire un checkout du dernier idf stable, 4.3.2

RASPIAUDIO commented 2 years ago

ma question n'était pas sur l'idf 4.3 , mais sur la version squeezelite à charger et comment la charger : qd je fais "git clone...." je récupère la version par défaut et non une version 4.3 (il doit y avoir qq chose d'éléméntaire que je ne sais pas faire...)

Pour la batterie, il faut que j'en parle avec Olivier. Ce qui est sûr c'est qu'il y a 1 cell. A+

philippe44 commented 2 years ago

Effectivement pour squeezelite si tu veux la branche qui contient cspot et qui correspond à idf 4.3 if faut faire un checkout de "master-v4.3".

Pour la battery, j'ai mis le coefficient qui correspond à 4.2v = 2300 sur le DAC et une cellule et ça a l'air cohérent

philippe44 commented 2 years ago

J'ai fait les changements pour intégrer la visualisation de la batterie, mais ça n'a pas l'air de marcher. Je te laisser regarder

RASPIAUDIO commented 2 years ago

OK je regarde ça au plus vite et je te tiens au courant (=> lundi)

Par ailleurs, j'ai bien du mal à récupérer la version master-v4.3... en gros j'utilise "git checkout" depuis le repo de la version par défaut... mais ça ne marche pas Comme je ne l'ai jamais utilisé, je suis bloqué. Si tu peux me donner la marche à suivre...

philippe44 commented 2 years ago

Tu as cloné la repository d'abord have un "git clone submodule --recursive" (vérifie la syntaxe, je me trompe toujours) ? Ensuite un "git checkout master-v4.3" devrait te donner notre base.

RASPIAUDIO commented 2 years ago

merci... c'est : git clone --recurse-submodules -j8 http.....

RASPIAUDIO commented 2 years ago

le point du jour: 1- il y a une petite erreur dans CONFIG_AUDIO_CONTROLS il faudrait remplacer \"longpress\":1000 par \"long_press\":1000 sinon l'appui long sur le bouton central ne marche pas (c'est moi qui est fait cette erreur au départ!)

2- Pour la batterie Pour passer des mesures brutes aux valeurs physiques il faudrait je crois:

J'ai quand même vérifié que tout marchait bien à part ce point:

Il a aussi le fait que la led ne s'allume qu'au bout 5mn (30 * 10 sec) Il faudrait peut-être faire un appel à battery_svc() des le démarrage

philippe44 commented 2 years ago

Je vais regarder mais je ne comprends pas ce que l'utilisation de valeurs brutes change. Les logs montrent bien qu'on reçoit une valeur bien convertie dans muse.c mais dans mon cas la led ne s'allume pas hors, quelle que soit la valeur, on devrait avoir une couleur.

Je préfère rester en valeur convertie car ça permet aussi d'indiquer une valeur réelle à LMS.

Pour le démarrage tu as raison, il faut une valeur initiale.

RASPIAUDIO commented 2 years ago

Là, il y a peut être un autre problème; ce que j'ai constaté moi avec ta version d'hier sans modification : la led s'allume en rouge mais au bout de 300sec Et c'est logique car la mise à l'échelle étant fausse ça ramème une valeur de 0.57 V qui est inférieure à VRED

Oui je suis d'accord pour rester en valeurs physiques c'est plus général et ça te permet d'intégrer d'autres cas...

Je m'y remets demain... je te tiens au courant

philippe44 commented 2 years ago

Tu peux me donner le code que tu utilises ? Je pense que ta version n'a pas la remise à échelle corrigée par ça me donne bien 4.4V, pas 0.6. C'est dans le dernier Kproject.build