mp3 or wav files 20-3khz 0db sweep do not trigger the overload however a sweep with intermittent full amplitude bursts from -6 to 0db repeatably cause the shutdown to occur.

Maurice if you want to put it in an earlier release please let me know which one.

Could you please try this with the latest build.

This still happens with the 9262 FW.

I find it easy to reproduce.

play internet Radio KGO news talk at full volume. NO Battery installed.

Wait unit will shutdown.

It's KG0 810 AM in San Francisco. go to Internet Radio->Search to find if you're not from SF Bay Area.

This came from a RightNow call


If I crank the volume all the way up while listening radio, it restarts. This happens always only when the volume increase occurs suddenly. There must be something wrong w/ its operating system, unless something wrong w/ the hardware.

Reported by factory as failure with 7.5.3 r9283. From e-mail:

"...Yes, it is caused by the adapter can not offer enough power when playing music at max volume, we did see the current (of Radio) was about 1.2A-1.3A(we measure it with HP6612 power supplier) while the fixed current of adapter is only 1A."

Raising priority to P1.

The goal would be to modify firmware (MSP?) to somehow prevent the shutdown by limiting the gain when this happens. That would not mean simply just limiting the current to 1A max because it would introduce audible and unacceptable distorted audio. The goal would be to limit the current intelligently so that the audio peaks just before it hits 1 amp.

Here's a discussion about this topic via this link:

http://www.dsprelated.com/showmessage/21943/1.php

Good luck!

Analyzing the format of the streaming data to understand what causes this situation. There are two conditions that triggers this bug:
 1. Go to radio sites like KGO 810 and keep the volume to 100. Ultimately the Baby reboots
 2. Sudden increase the volume from 0 to 100 and wait for 5 seconds. At times this bug happens.

 Inside the Playback.lua we have a mapping of the volume to gains. This eventually is multiplied by each PCM to generate the output buffer.

The PCM is getting multiplied by the lgain and rgain, which are calculated based on a mapping of volume ( from 0 to 100 ) to Gains(from 16 to 65536).
Playing Radio KGO 810 on volume 90 for a while causes the Baby to reset as well. It seems that there are patterns that are capable of putting a lot of load on the Baby.

We need some signal processing to keep the amplitude of the woofer under control to avoid exceeding 1A (we probably don't need to worry too much about the tweeter as the impedance is higher).
The MX25 knows the gain of the codec, so it could compute the current flowing in the woofer assuming a constant 4ohm impedance. If the current exceeds 1A, the MX25 will clip the signal going to the codec. This method is a little bit crude and may clip the signal even when it is not needed (around the resonance frequency). 
A better approach is to use a more accurate model for the impedance of the woofer that takes into account the resonance frequency but that requires more complex signal processing as the impedance depends on the frequency. Audio BU should be able to provide an algorithm to know when we exceed 1A knowing the characteristics of the woofer.
I would put a current probe on the 18V and monitor the shape of the peaks before and after processing.

Created attachment 7238 [details]
MP3 file that could reset the Baby.

This file can reproduce the problem in a very short period of time. Thanks to Ryan.

There are several layers that are involved in playing audio. Here is my preliminary understanding of the big picture:
 1. Receiving the commands to play the music and increase/decrease the volume:
        Typically the lua files. The volume is transformed in Playback.lua from [0-100] to gains. Start from luaopen_decode and "luaL_Reg decode_f" definition in trunk/squeezeplay/src/squeezeplay/src/audio/decode/decode.c
 2. The decoding of music happens based on the type of the audio file. Check out the squeezeplay/src/squeezeplay/src/audio/decode/decode.c
        Here are some examples:
struct decode_module decode_mad = {
        'm',
        "mp3",
        decode_mad_start,
        decode_mad_stop,
        decode_mad_samples,
        decode_mad_callback,
};
struct decode_module decode_pcm = {
        'p',
        "aif,pcm",
        decode_pcm_start,
        decode_pcm_stop,
        decode_pcm_samples,
        decode_pcm_callback,
};

 3. After the music stream is received and decoded based on its type the output buffer is transferred to alsa layer.
   Check out squeezeplay/src/audio/decode/decode_alsa_backend.c and playback_callback function. The gains are integrated into the output buffer by:
        *(output_ptr++) = fixed_mul(decode_audio->lgain, *(decode_ptr++)) >> 16;
   The snd_ functions are used to transfer the data kernel by using alsa library. Here are some examples:
        snd_pcm_open
        snd_pcm_mmap_commit
        snd_pcm_hw_params_any
 4. alsa-lib defines the snd_ routines. Here is the path: trunk/squeezeos/poky/build/tmp-baby/work/armv5te-none-linux-gnueabi/alsa-lib-1.0.18-3/alsa-lib-1.0.18
 5. The kernel drivers and related functions could be found at:
linux-2.6.26/sound/soc/imx/baby-tlv320aic3104.c
linux-2.6.26/sound/soc/imx/imx_pcm.c
linux-2.6.26/sound/soc/imx/imx-ssi.c
linux-2.6.26/sound/core/pcm_lib.c
linux-2.6.26/sound/soc/oc-dapm.c // ALSA SoC Dynamic Audio Power Management
linux-2.6.26/sound/soc/codecs/tlv320aic3104.c
linux-2.6.26/sound/core/control.c

I will update this as I have a better understanding of the whole stack.

Following links helped me understand this better:
http://en.wikipedia.org/wiki/Equalization
http://en.wikipedia.org/wiki/Digital_biquad_filter
http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt

Mickey to take a look for more info. Felix to code review first, and then PQA to test special build before rolling it into regular build.

Custom test firmware built based upon 7.5.4_r9441 version. Change affects the audio path only and does not impact any other software components.

Will put custom firmware into Google Docs.

I found this email from Vahid. He sent it on June 7 2011.


Hello,
By changing the POWER_LIMIT in the babydsp_pcm.c we can prevent this
bug from happening. I have been running extensive testing with the
value 18500 and the problem does not happen(I am testing with
different values and also trying to have a better understanding of the
code).
However I am not sure how much impact this will have on the loudest
music we can play(or on the quality of music). Honestly I cannot say
the difference with my ears.
Does anyone have a good suggestion of how we can test the impact of
this change.
Regards,
--Vahid
Here are the instruction to fetch and make the changes:
#bitbake squeezeos-dsp -c compile -f
Here is the path to the file:
squeezeos_dsp/src/babydsp_pcm.c
If you build this the result will be under the .libs/ directory and by
copying the shared library to your Baby you will have the changes:
/usr/lib/alsa-lib/libasound_module_pcm_babydsp.so

I've checked svn 7.5 and 7.6 for changes to the file (babydsp_pcm.c) Vahid is mentioning and the proposed change has not yet been commited.

This is what 'svn blame babydsp_pcm.c' (for 7.5 and 7.6) is reporting:

  6401     ccrome //#define POWER_LIMIT 18500
  6404     ccrome #define POWER_LIMIT 25500
  6382     ccrome //#define POWER_LIMIT 160
  6270    richard /* output count has to be a multiple of 5 */
  6280    richard #define OUTPUT_COUNT 250
 
Caleb seems to have increased the power in r6404. Not sure why though.

Handing over to Felix to review the change.

Forumthread about the problem:
http://forums.slimdevices.com/showthread.php?p=635261#post635261

I am having the very same problem with one of my Radios. It consistently crashes when specific, rather bass-heavy music plays at full (usually 90+) volume.

Also I have seen the current drop (even below 15V sometimes) just before rebooting.

 == Auto-comment from SVN commit #8475 to the player repo by fmueller ==
 == http://svn.slimdevices.com/player?view=revision&revision=8475 ==

Bug: 15729 
Description: Lower POWER_LIMIT to 18500 (was 25500) to prevent SB Radio from rebooting when music with heavy low frequency is played at loud volume (max).

I do not see this change in a build yet ....

can you explain what you mean by "see" this in a build?

The change should be in r9447, and 7.6.0 is pushing r9449 currently...

Has anyone tested this lately using the most recent firmware?

So is this fixed or not? Anybody???

(In reply to comment #27)
> So is this fixed or not? Anybody???

I am able to use my Radio at full volume, so it seems to be fixed. :)

Someone please close this unless there are still issues.