• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 64 subscribers
  • Views 1168 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TPS65950: Audio "pop" at beginning of playback

Andy57432
Prodigy 60 points
Other Parts Discussed in Thread: TPS65950

Hello all,

I have set up a custom audio driver using the McBSP2 module on the OMAP 3530, and the audio codec in the TPS65950. I originally set up the driver such that the McBSP2 was the audio "master" (ie, transmits the frame sync and and data clk) and the audio codec was set up in slave mode. This seemed to work perfectly, and playback was noise free.

Unfortunately, due to hardware changes (clk_256fs line from TPS65950 is not connected any more), I was forced to change the driver such that the audio codec is the "master" and McBSP2 is slave. I have been able to get audio playback to work, but I am getting a loud "pop" right at beginning of playback of any audio phrase. It only happens at the beginning, the rest of the playback is perfect.

I am not turning the audio codec on and off in between playback, I simply turn it on once and leave it on.I am a little be baffled by this problem, especially since it does not happen when the OMAP/McBSP2 is the audio master. Any ideas on what might be causing this issue?

Thanks,

Andy

  • 0
    TI__Genius 15100 points

    Hi Andy,

    Pop should be a problem only when the amplifiers are not powered on in the right order. You can refer the TRM for the correct order.

    Which analog output  are you using?

    Since you had no pop when using McBSP as master then I would assume that the sequence is correct. However, it is better to double check.

     

    Regards,

    Gandhar.

  • 0 in reply to Gandhar Dighe
    Prodigy 60 points

    I am using the Headset Outputs. I am following the "Multimedia Player Use Setup" in programming guide section of TRM as a guide for initialization. I assume this would contain the correct order for powering the amplifiers?

  • 0 in reply to Andy57432
    TI__Genius 15100 points

    Hi  Andy,

    Can you please refer to page 699 in TPS65950 TRM. You may be missing the RAMP_DELAY setting.

     

    Regards,

    Gandhar.

     

  • 0 in reply to Gandhar Dighe
    Prodigy 60 points

    I am initializing the amplifier according to the steps on page 699, and have set the RAMP_DELAY to enabled. I am reasonably sure that this is configured correctly, as I do not get the pop noise on initialization of the audio codec (where amplifiers are turned on).

    The pop only occurs very briefly at the beginning of playback of an audio file. I am using DMA on the OMAP/McBSP2 side to transfer the audio data. I have tried removing the DMA and sending the data by hardpolling the McBSP2 "transmit ready" status, and the same pop noise occurs. This combined with the fact that the noise does not occur when OMAP/McBSP2 was master makes me think the problem is not on the OMAP/McBSP2 side.

    It seems maybe I am missing some piece of configuration on the TPS65950 that is needed when the audio codec is master?

     

  • 0 in reply to Andy57432
    Intellectual 480 points

    If I understand your post correctly, you are essentially initializing everything once and playing one big long audio stream with random long periods of no data; starving the decoder to create silence between files.

    If this is correct, since you are not re-initializing the audio drivers and hardware between audio files, I suspect you are hearing the discontinuity between the last audio sample of the previous audio file and the first sample of the next audio file.

    That is, if the last audio sample was 0x00 and the next audio sample is 0xFF you will hear a pop as the speaker is slammed its full range. You will not hear the pop anywhere else because the samples are all part of a continuous stream. The RAMP_DELAY may be having no effect because you are not doing anything to invoke it.

    -- Chip

     

  • 0 in reply to ChipD
    Prodigy 60 points

    ChipD,

    You are correct, I am not reinitializing the audio hardware between playing audio files, but I don't think I need to since I never power off the audio codec. I am disabling transmit on the OMAP McBSP2 transmitter after audio playback of a file is completed, and then reenabling it when a new play request is generated.

    I believe the RAMP_DELAY is used to eliminate noise when the amplifier is powered up or down. It accomplishes this, and I do not get the noise on powerup/powerdown. I think you are correct that it will not help with the issue that I am encountering.

    Again, this issue did not appear when the codec was "slave". It only seems to happen in the audio codec "master" configuration.

  • 0 in reply to Andy57432
    Intellectual 480 points

    From what you describe, I think your code is fine and this is a case of the computer doing exactly what you are telling it to do instead of what you want it to do. ;)

    If I am correct, the pops are in your audio data, not your code. You can test this fairly easily by pasting the audio samples from all your audio files into a single large file, making sure to remove any headers to make a single seamless stream. When you play this file on any media player you should hear exactly what you hear now, including the pops but without the silences. An even easier check is to simply print out the first and last sample values (for each channel) and you should see large differences exactly where you hear the pops.

    The whole purpose of the RAMP_DELAY in hardware is to mitigate these pops since there is always this discontinuity between audio files, but you have bypassed the RAMP_DELAY by never shutting down the audio playback.

    One way to fix this is to implement your own RAMP_DELAY in software by adding 100-200ms of your own audio samples to the beginning and end of the audio files. At the beginning, these samples ease the output speaker from a constant neutral value to the first real sample value. At the end, they smoothly ramp from the last real sample value to the constant neutral value. This way there is always a smooth transition between files.

    A variation on this is to apply a sliding scale factor to the first and last 200ms of samples to implement a "fade in" and "fade out" effect. This has the advantage of not introducing any delays or extra audio.

    Another fix is to let the audio hardware do this for you by letting it know when a discrete audio file is beginning and ending by putting your startup and shutdown code back in between files.

    You are correct that you don't need to re-initialize, but by skipping this step you have changed the way the audio hardware sees the data. You see five separate audio files, it sees only one.

    I think the real mystery here is why you did *not* hear the pops before.

     

  • 0 in reply to ChipD
    Intellectual 480 points

    One more thing: It is important to know where "neutral" is for your speakers. It is probably mid-range, not zero. Setting the output to zero will typically keep the speaker energized at the "full-in" position like a coiled spring, just waiting to "pop" back to neutral when power is removed.

  • 0 in reply to ChipD
    Intellectual 480 points

    <pedantic> I was using unsigned values above; zero *is* midrange for signed values. </pedantic>

  • 0 in reply to ChipD
    TI__Genius 15100 points

    Thank you ChipD.

    Andy - Does this make sense. From device point I dont think you are missing anything. So, this would be worth trying.

     

    Regards,

    Gandhar.

     

  • 0 in reply to Gandhar Dighe
    Prodigy 60 points

    I have resolved this issue. I am embarrassed to say that the problem was is my audio file processing, and not related to the audio hardware at all. When setting the pointer to the actual sound data in my sound files, I accidentally was including the last 4 bytes of the header. This was causing the pop noise at the beginning of audio playback. I cannot explain why I did not hear the poping when OMAP was audio master.....maybe that was due to another bug ;-) .  But the issue was definitely in my file processing.

    Gandhar and ChipD, thanks to both of you for your help in debugging this issue!