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.

PCM5142: PurePath Studio Volume block strange behaviour

Part Number: PCM5142
Other Parts Discussed in Thread: PUREPATHSTUDIO, , PCM5242

Hello!

Block "Volume" in PurePath Studio behaves very strange. When coefficient is less than 0x010000, when changing from -36 dB to -36,5 dB, volume does not vary smoothly but falls down to small level.

When using block "Volume_ZeroX_ROM" volume level changes smoothly as it should but during volume changes sound is distorted.

Thank you.

Best regards,

Evgenij

  • Hi Evgenij,

    Can you share your purepath process flow?

    Thanks,

    Paul

  • Hi, Paul.

    Purepath process flows attached.

    Thanks,

    Evgenij

    Volume_ZX_ROM.zipVolume.zip

  • Hi Evgenij,

    Have you tried removing the stereo_balance block? does that have an effect? Unfortunately, I do not have access to my lab to confirm this for a few more days.

    Thanks,

    Paul

  • Hi, Paul.

    I have tried process flow without stereo_balance block. Removing stereo_balance block has no effect, nothing changed.

    Thanks,

    Evgenij

  • Okay, that is interesting.  When you change the volume, are you using the adjustment control in the purepath studio, or are you actually volume register on the device?

  • Hi, Paul

    Volume is changed via "Volume" block in PurePath Studio process flow only, register volume stays untouchable.

    Thanks,

    Evgenij

  • Can you try implementing the process flow and then use the actual volume registers to adjust the volume? My suspicion is that the PPS GUI does not smoothly update the coefficient.  

  • When using block "Volume_ZeroX_ROM" volume level changes smoothly as it should but during volume changes sound is distorted. Both "Volume_ZeroX_ROM" and "Volume" use the same volume coefficient. But volume changes smoothly only when "Volume_ZeroX_ROM" is used. But when "Volume_ZeroX_ROM" is used, output sound is distorted during volume changes.

    I also tried changing volume by means of volume registers. The result is the same as with "Volume_ZeroX_ROM": volume level changes smoothly but output sound is distorted during volume changes. So by now none of volume change means - "Volume_ZeroX_ROM" block, "Volume" block, volume registers - allows to change volume correctly.

    Thanks,

    Evgenij

  • Okay, so I tested this in my lab today. 

    The volume blocks in the process flow are useful for defining where in the flow the volume adjustments are applied.  The reason why the audio is glitchy when you adjust the volume in PurePathStudio is that it updating the single coefficient in the either the CRAM A or CRAM B.  This is not the expected use case in application.  The volume value in the flow can be considered a baseline value for the DAC.  

    There are volumes controls in the non-coefficient memory, these are located on page 0, register 0x3C, 3D, 3E.  

    So for example, this is how you might use the volume block:

    The max output of the PCM5142 is about 2.1VRMS.  Let's say you have an amplifier that that can take a max input of 1VRMS.  You would use the volume block in the process flow and set the DSP coefficient to -6dB.  This would attenuate the output by 50%.

    Now during normal use, you would use registers 0x3C-E to control the volume of the application.  If you enter 0dB in those registers, the output would still be 1VRMS.  If you enter -6dB, the output would be 0.5VRMS.  

    I hope that makes sense.  This is beneficial as you can change the volume without touching the coefficient memory.

    Thanks,

    Paul

  • Hi, Paul,

    Below is the conclusion after many experiments with pcm5142. Please confirm or refute each point, they are very important for our design.

    1) You say: "The volume blocks in the process flow are useful for defining where in the flow the volume adjustments are applied.  The reason why the audio is glitchy when you adjust the volume in PurePathStudio is that it updating the single coefficient in the either the CRAM A or CRAM B.  This is not the expected use case in application.

    I repeat once more: there are no glitches when using simple "Volume" block; sound is clear as it should be. Glitches appear only with "Volume_ZX_ROM". But with "Volume_ZX_ROM" volume always changes smoothly, and with "Volume" block volume falls down when value less than 0x010000.

    You say: "The volume value in the flow can be considered a baseline value for the DAC".

    OK. If so, why using simple "Volume" block and "Volume_ZX_ROM" block do we have absolutely different results at the output with the same -38 dB level in PurePathStudio? We do not regulate volume, just boot PCM5142 and have different output volume.

    Our conclusion: "Volume" block works incorrectly even at startup. Please confirm or refute.

    2) You say: "The reason why the audio is glitchy when you adjust the volume in PurePathStudio is that it updating the single coefficient in the either the CRAM A or CRAM B.  This is not the expected use case in application.

    If so, what is adaptive mode intended for?

    Can we change any DSP coefficients on the fly? Please confirm or refute.

    3) There are glitches while changing volume even by means of volume registers. What could be the reason?

    Thanks,

    Evgenij

  • Hi Evgenij,

    Let's see if I can clarify a few things:

    1. I am confident that the glitches are caused by PurePath Studio (the program) interacting with the DSP.  It is likely not handing the adaptive mode access correctly, which is causing the DSP to load coefficients in an erroneous way.  Are you see this notification as well?

    That is an error I get when I am using the volume block.  My understanding is that the PPS tool is forcing the device out of adaptive mode so that its register probing tools still work.  I think a good workaround while you develop your process flow is to disconnect, change your volume levels, and then "download and run" again.

    Try this: use the I2C Command tool to load in PurePath Console 1.16 the following config file. (note that I am using PPC 2.0 because I am debugging this with the PCM5242, but they have the same DSP).  This config file loads the process flow shown above, but I have volume set to be 0dB in CRAM A and -12dB in CRAM B.

    base_main_Rate44 0db cramA -12dB cramB.cfg

    switch CRAM in adaptive mode.cfg

    Using the load and execute options, load the file with the CRAM values.  Now you can play some audio, which should be at 0dB.  Next load and run the "switch CRAM in adaptive mode" script.  This switches from CRAM A to CRAM B and vice-versa.  You can execute this multiple times to switch back and forth.  You should hear a smooth (clip-less) transition from 0dB to -12dB.  

    Now, this volume adjustment required access to the CRAM, which is probably not how you would want to implement a simple volume change in your actual application.  

    More likely, if you wanted to adjust the volume on-the-fly, you would use the digital volume adjustment that is not in the CRAM.  In PPC2.0 that is available on the same page.  If I set it to -6dB, I now get an effective volume of -6dB when using CRAM A and -18 dB when using CRAM B.

    Now, to your point "OK. If so, why using simple "Volume" block and "Volume_ZX_ROM" block do we have absolutely different results at the output with the same -38 dB level in PurePathStudio? We do not regulate volume, just boot PCM5142 and have different output volume."

    Ultimately I do not know.  But I would suggest you try the option where you use the disconnect>modify>download and run and see if you still have a difference.  To your other comment, about the boot-up volume: note that the PCM5142's memory is volatile, so power-cycling the device will clear all coefficients. 

    2. Adaptive mode would be better suited to implement different coefficients for your biquad filters or DRC, etc.  User instigated volume adjustment should be down with registers on Page 0.

    3. I do not have any issue changing volume with the volume registers.  Are you testing this on the EVM? Are you disabling any other volume-related features?  I highly suggest testing some of these features in PPC1.16.

    Thanks,

    Paul

  • Hi, Paul

    1) We use our device board with PCM5142 which is booted by external MCU. So we don't use PurePath Studio to interact with the DSP and can't see such a notification. Thanks for that!

    Though it is becoming even stranger. We regulate volume, biquads, balance, etc. on the fly by external MCU. As I wrote earlier, glithces appear with block "Volume_ZeroX_ROM" not with block "Volume".

    With block "Volume" when changing from -36 dB to -36,5 dB, volume falls down to small level. And with block "Volume_ZeroX_ROM" otherwise volume level changes as it should but with glitches heard during
    changing. We definitely do CRAM buffers change properly as changes really take place, and with biquads we have excellent output sound while changing coefficients on the fly.

    Now, to your point "OK. If so, why using simple "Volume" block and "Volume_ZX_ROM" block do we have absolutely different results at the output with the same -38 dB level in PurePathStudio? We do not regulate volume, just boot PCM5142 and have different output volume. Ultimately I do not know.  But I would suggest you try the option where you use the disconnect>modify>download and run and see if you still have a difference.  To your other comment, about the boot-up volume: note that the PCM5142's memory is volatile, so power-cycling the device will clear all coefficients."
    In our design PCM5142 is booted by external MCU. So every time at startup we boot PCM5142 with the whole .cfg file generated by PurePath Studio. In other words we have -38 dB with "Volume" block is completely different to -38 dB with "Volume_ZX_ROM" block.

    "Now, this volume adjustment required access to the CRAM, which is probably not how you would want to implement a simple volume change in your actual application."
    Why not? Moreover in PurePath Studio there is "Volume_ZX_ROM" block with zero crossing. So why do one need zero crossing detection at boot up use only?

    2) Yes, while changing biquad coefficients on the fly we have clear output sound.

    3) We are going to experiment deeper, thank you. Can We use PurePath Console only with EVM or also with our own board?


    Thanks,
    Evgenij

  • Hi Evgenij,

    PurePath Console really only works on with the EVM.  It has the I2C feature that allows .cfgs to be loaded easily.  

    I have not been able to reproduce this issue you are seeing but I did see some weird behavior when using the .pfw files that you shared.  Are you still using the STEREO_BALANCE component? Does removing it make a difference in your system?  I found that occasionally only one channel would work and I was getting a DSP overflow error.  Can you confirm if you are seeing the same error? You can check by reading Page 0, Register 90.

    In addition, can you detail the steps you are taking to monitor the active CRAM and safely switch the values?  

  • Hi, Paul,

    STEREO_BALANCE component is removed from process flow, but it changes nothing. I will check error status in Page 0, Register 90.

    CRAM buffers are swapped according to SLAA425D document "Coefficient RAM Access Mechanisms", steps:

    1) write new coefficients

    2) switch buffers

    3) wait for switch flag to clear

    4) write new coefficients once more

    I think our switching procedure is correct because while changing biquads coefficients output sound is clear and changes take place as expected.

    Thanks,

    Evgenij

  • Hi Evgenij,

    Can you confirm if you verify which CRAM is active before you write to the other CRAM?

    As I have not been able to reproduce this behavior, it is difficult for me to diagnose this.  I recommend you remove the volume control from the process flow and instead rely on the volume control for the I2S input (Page 0 registers).  The volume block does not provide much unless you are trying to adjust the volume of a single audio path (e.g. if you want the left channel to always be a lower volume than the right channel).  

    Thanks,

    Paul

  • Hi, Paul

     

    "Can you confirm if you verify which CRAM is active before you write to the other CRAM?"

    Why? User can access only one buffer at any time and according to switching buffers procedure I update data in both buffers.

    Please show me the place in SLAA425D document (maybe in other document) where it is described that user must verify which CRAM is active before writing to it?

    "As I have not been able to reproduce this behavior, it is difficult for me to diagnose this. I recommend you remove the volume control from the process flow and instead rely on the volume control for the I2S input (Page 0 registers). The volume block does not provide much unless you are trying to adjust the volume of a single audio path (e.g. if you want the left channel to always be a lower volume than the right channel)."
    I see.

    Thanks,

    Evgenij

  • Hi Evgenij,

    My recommendation to confirm the CRAM was in an effort to prevent synchronization issues:

    The ACRS will notify you of which bank is being used.  That way you can ensure that you are only writing to the CRAM that is not being used.  You should not modify the CRAM that is currently being used by the DSP.  

    Think of the two CRAMs as a ping-pong buffer.  You modify the unused CRAM, then request a switch.  You can then modify the previously used CRAM.

    Thanks,

    Paul

  • Hi, Paul

    Your suggestion is completely opposite to documentation.

    According to documentation CRAM buffers cannot be accessed simultaneously by DPS and user which is guaranteed by design: when CRAMA is used by DSP, it cannot be accessed by user and vice versa.

    That is why CRAM buffers do not have addresses to be accessed directly, buffers can only be switched.

    If you suggest to check active CRAM and write to another, so please provide exact procedure how to do that and CRAM buffers addresses.

    Thanks,

    Evgenij

  • Hi Evgenij,

    You are right! I have misunderstood the adaptive mode and for the last few years. I have always verified which CRAM was in use before writing.  I just tested this and confirmed that the CRAM bank does not matter.  So it is not necessary to check the ACRS bit.

    That being said, I still have not found any distortion when adjusting the volume coefficients.

  • Hi, Paul

    I think the discussion could be stopped with the following conclusion: volume blocks in PurePath Studio must not be used for dynamic volume level regulation, instead volume registers must be written for that purpose.

    Thank you for your answers.

    Best regards,

    Evgenij