Idle power consumption

[luar123]

Hey everyone, I have been looking into reducing idle current and want to share findings and get some new ideas.
My setup is not optimized and consists of a ESP32 DevKit with pcm5102a dac. I will always compare current floor. There are higher peaks when e.g. wifi is transmitting, so to be more accurate we would need to integrate over some time. But for a first comparison floor is good enough guess.

Default idle current is around 83mA, not too bad but still, the device is doing almost nothing.
Power management needs to be enabled through menuconfig (components->powermanagement) and then activated in the code. With this CPU frequency scaling can be activated. Automatic light sleep mode requires additionally tickless idle freeRTOS mode (components->FreeRTOS->tickless idle).

Using this, idle current can be decreased to:

• CPU freq scaling only: 59mA
• additional light sleep: 22mA

So I configured frequency scaling and if available automatic sleep mode.
Then I used initially a lock to deactivate it when music is playing (I set the lock in the audio_set_mute function). This is working after boot-up, but once the device is muted and un-muted again, it is out of sync. I figured that some timers got confused by the frequency scaling and tried to automatically stop the player task whenever the device is muted or music is stopped and then re-initialize it when music resumes. I got this working after some try and error and with light sleep and freq scaling it seems to keep the sync. However, for freq scaling only it gets out of sync again. Additionally I am not sure if stopping the player task is the right thing to do. It should be enough to reset the sync when music resumes.

You can find a proof-of-concept in https://github.com/luar123/snapclient/tree/power_reduction
(You need to configure your board and enable power management through menuconfig.)

I have two questions:

• Any thoughts on how to best reset the sync after power management is disabled / music is resumed?
• According to espressif docu: Enabling power management features comes at the cost of increased interrupt latency: 0.2-40uS. Do you think (or can someone test and measure) this will have a significant influence on the overall sync?

[CarlosDerSeher]

Great you are getting this started, this has been on my task list for a long time just not a real high priority. I couldn't make it work and keep up sync right away so pushed it aside.

One thing that could be an issue in player task is the hardware timer used for inital sync. I believe its clock is influenced by frequency scaling?! Maybe take a lock while waiting for initial sync helps?

The other thing which could be problematic is a jittery latency measurement because of power management. Have a look at esp_timer and how it is affected by PM. This is used for the time ping-pong with the server. I think relevant lwip send functions are called by periodic timer callbacks, maybe a bunch are missed because of sleep and then sent in a row.

I don't think 40us will be a problem in a multiroom setup. For stereo speakers they probably are. If you have a oscilloscope you could use two boards and and measure the same channel on both to see sync. Use a metronome signal 120bpm or similar.

[luar123]

Yes, esp_timer is definitely influenced by the frequency scaling and I believe this messes with the sync in the normal implementation. With the modified player task a lock is taken whenever the player task is running and the timer gets initialized new each time.

Light sleep shouldn't be a problem as it is supposed to wake up when a timer callback is due, but I need to look further into the latency measurement. Where exactly is this ping-pong happening?

I will try to do some measurements in the next days.

[CarlosDerSeher]

Ot is somewhere in main.c, look for
SNAPCAST_MESSAGE_TIME

And when you say it gets reinitialized, do you mean it's counting value is reset? If so then there is your problem

[CarlosDerSeher]

Maybe it will be agood idea to also take a apb and/or light sleep lock during the time while waiting for the time message response from the server

[CarlosDerSeher]

I did set APB max to 80Mhz once and it did work flawless, so maybe disabling DFS completely and just setting the clock to its lowest setting will be a good solution?

[luar123]

Finally, I was able to get some useful measurements. My reference is a x86 server that generated a lot of noise on the scope, so I needed some additional filtering. I really need to get a second esp+dac

Anyway, here are the results, energy average over 0.5-2h:

1. master branch, without PM:
   0.84W when playing
   0.4W when mute
   time difference +/-0.2ms
   after un-mute the diff is higher, and goes down to the usal range within a few seconds
2. my proof of concept branch, without pm, cpu freq=240MHz:
   same as master
3. my proof of concept branch, without pm, cpu freq=80MHz:
   0.78W when playing
   0.34W when mute
   same sync/behaviour as master
4. my proof of concept branch, with pm DFS+Lsleep, cpu freq=240MHz:
   0.84W when playing (pm disabled)
   0.2W when mute
   time diff +/-0.2ms
   after un-mute the diff is much higher (sometimes >>10ms), and takes a few minutes to go down to the usual range

Conclusions so far:

• your syncing is really good :-)
• CPU scaling gives no big power saving
• light sleep has biggest impact
• disable PM while playing
• when PM is enabled sync is not kept, solutions:
  • try to keep sync,maybe by taking a lock while getting time from server
  • force to reset/recover the sync once pm is disabled

Not sure what's the best solution. When I have time I will experiment more.

[CarlosDerSeher]

Reads like you are putting lots of effort in there, thumbs up for that 👍 and yes I also put in a lot of effort to sync so thanks :)

So here it goes:
Another thing you should consider is the server not sending audio. Clients should enter power management in that case too. This is the situation for my setup at least. Maybe just kill player task.

A possible solution for the time sync problem could be to clear the latency buffer and do a new initial sync with the server. This will put a bit more stress on the network but could be a fast solution for now.

[CarlosDerSeher]

Found another interesting thing

https://github.com/bitluni/ULPSoundESP32

Uses ULP for audio out. Not sure if this could be done for i2s audio too.

[luar123]

Not sure if ULP could theoretical work, but I don't want to look into it. Ok, maybe on ESP32-S2, but on the others you have to code in assembly...

[CarlosDerSeher]

I don't really think ULP would be practical or even possible. APLL will always need to run and I2S / DMA, from what I read, isn't able to wake up the processor from light sleep.

[luar123]

Got it working now.

So here it goes: Another thing you should consider is the server not sending audio. Clients should enter power management in that case too. This is the situation for my setup at least. Maybe just kill player task.

That's actually my current implementation. Muting is ignored, but when the pcm queue is empty, the player_task will kill itself.

A possible solution for the time sync problem could be to clear the latency buffer and do a new initial sync with the server. This will put a bit more stress on the network but could be a fast solution for now.

Thanks, that was the missing part :)
Also had to set timeout = FAST_SYNC_LATENCY_BUF in order to keep the delay until playing starts low.

So my current implementation is:

• init player_task (but don't start)
• when pcm chunks are inserted player_task is started
  • take apb lock
  • start timer
  • reset latency buffer
  • create settings/pcm queue
• when pcm queue is empty, stop player_task
  • stop timer
  • delete queues
  • release lock
  • delete task

This is working fine, but I don't like the implementation and won't create a PR. Now I would keep player_task running and just take/release locks, resync, block task etc when needed.
Additionally, I think it would be a good idea to put all audio_HAL handling (mute, volume) in one task. Player_task already handles all i2s and also knows when there is nothing to play, so this would be a good fit. Finally, player task could inform http_task of its state (playing/paused) in order to get FAST_SYNC_LATENCY_BUF as fast as possible.

If you agree, I would implement this and create a PR for it. Might take a while, though...my time is limited :D

[luar123]

Additionally, I think it would be a good idea to put all audio_HAL handling (mute, volume) in one task. Player_task already handles all i2s and also knows when there is nothing to play, so this would be a good fit.

While working on this I am not so sure anymore if it is a good idea. Depending on the DAC it could include some i2c writes. Do you think it is ok to have such a delay in the player task? Or would it be better to keep it in the http task?

[CarlosDerSeher]

I can't remember if these are blocking writes or not. If the i2c driver handles the communication in its own task and the jobs are only put to a queue from player task it is ok but every delay in player task will affect sync because at the beginning of the loop we read server_now and at the end there is the control code.

Another thing that came to my kind is DAC current consumption. Not sure if the supported codecs are all send to sleep while muted or when no chunks are received. I guess it is done for the lyrat but if you have muse you could also evaluate if there can be saved some more mA :)

[luar123]

It seems i2c is blocking. On the other hand, handling settings like muting/volume change would happen at the very beginning of the loop before server_now().

I have looked only into pcm5102a which is set to sleep mode when it is muted. So yes, could be missing for some DACs.

[CarlosDerSeher]

On the other hand, handling settings like muting/volume change would happen at the very beginning of the loop before server_now().

Then we should get away with doing these i2c calls I think (didn't look at the code though).

[CarlosDerSeher]

On the other hand syncing relies on getting the next chunk as fast as possible after i2s_write() and evaluate if we are in time or not. So any delay in this loop is really bad. A possibility would be to put a timeout in i2s_write() and do those i2c calls on i2s write timeout and then try again to i2s_write? Not sure if this is a good solution as it could still introduce a delay from time to time as we have no way of knowing how much time is left until i2s write will succeed with requested amount of bytes.

Probably the median filter will make this delay even unnoticeable...

[DerPicknicker]

I have nothing to commit but a question in general. Is there a way to power down the dacs if they aren't used for some time..?
My board supports powering down the dac via an single pin / i2c commands. This should be also part of the energy saving mechanism. I would guess that you can save 0,5w-1w on dacs with built-in amplifiers.

[CarlosDerSeher]

Please check out audio hal from ADF2.4.

There is also a function called pa_enable or similar. audio_hal_ctrl_codec would need to be called just before entering power saving. In this function you'll have to set the gpio as needed.

For some dac's it's enough to mute them so they enter low power mode.

Disclaimer: all these things I recall from heart so don't take this for a 100% sure. Please do some research around ADF and how they do it for their boards.

[luar123]

Ok, so basically this function should be called every time audio_hal_mute() is called. We could use audio_set_mute() for that.

[CarlosDerSeher]

I think it is called audio_hal_set_mute() And yes I think muting would be a good way to put the DACs to sleep don't you. Also the PA could be powered down if we mute. In later ADF revisions there is also a pa_enable function but I'd just opt for mute == sleep and implement the functions this way

[DerPicknicker]

I think the main question is:
What must the driver do, to support the power down by the function mentioned above? Is the power down in the mute function located?

The driver of the dacs must somehow support the powerdown functionalities or not?

[CarlosDerSeher]

These functions need to be called from player context, when pcm chunks start arriving and if no pcm chunks are available for x seconds