channel swapping even when using mic input?

Writing software for systems that use VLSI Solution's devices as slave codecs to a host microcontroller.
Post Reply
Posts: 1
Joined: Wed 2018-11-28 2:06

channel swapping even when using mic input?

Post by Arjen » Wed 2018-11-28 2:49


We have a product that uses the VS1063a to encode audio from a microphone and pass it on to a MCU which stores the compressed audio together with other sensor data to a SDcard. We let the system do a self-check on the audio chain by running in PCM mode and let the MCU check for a certain audio level to make sure the microphone and pre-amp work correctly. After a successful self-check we switch to encoding mode to actually start storing audio.

Every now and then (really not very often, we haven't at all been able to reproduce this in the lab) we end up with no audio (just tiny bit of noise) when it did pass the self-check and as we ran it again (full power cycle of the system) all works fine.

We did not load the firmware patch before and I feel it might have something to do with the ADmixer-channel-swapping bugs even though we run it in mono mode and using the mic input. Does that make sense or is there no way this bug is related? (looking for some confidence here since we cannot reproduce this problem in the lab)

Also we noticed our battery life is reduced by about 10% after we started loading the patch. Could it be that the VS1063a is consuming a few milli amps more with the patch loaded?

Thanks a lot for any help!

User avatar
VLSI Staff
Posts: 1535
Joined: Thu 2010-07-15 16:04

Re: channel swapping even when using mic input?

Post by pasi » Wed 2018-11-28 12:07

It is the same channel swap issue. The Analog to Digital Converter is always stereo whether you use just one channel or not.

You can avoid the channel swap by using the patches package or by giving a hardware reset before starting (or after ending) encoding. For example the vs1063 standalone recorder performs a watchdog reset after creating the file so that it is ready for the next encoding. This may not be very practical in your use case though.

With the patch the encoding mode (always) uses the clock adder field from SCI_CLOCKF. This is done to allow higher clocks for mp3 and ogg vorbis encoding when you want to use the "exact rate" feature. If you have a non-zero value in CLOCKA, it could explain slightly higher power consumption. I don't think any of the patches themselves would measurably increase the power consumption (unless you use some new features).
Visit VLSI Solution on Facebook

Post Reply