SCI_WRITE .plg plugin to VS1053b takes too long

[nomnom-ray]

Hi,

Related hardware (from Adafruit):

• VS1053 Codec + MicroSD Breakout - MP3/WAV/MIDI/OGG Play + Record - v4
• Adafruit Feather M0 (a SAMD21 microcontroller like the Arduino zero)

Goal:

• record voice in ogg format using VS1053; controlled by feather M0.

What's working:

• clear audio recorded and stored to the SD card (supported by the VS1053 shield from adafruit)

What's the problem:

• the plugin for the VS1053 to record in an ogg format takes 3 seconds to load into VS1053b's RAM
• Context: Using the micros() function, I'm able to calculate that the SCI_WRITE() function provided by Adafruit takes 160us. The SCI_WRITE() is invoked ~21000 times by a function similar to an VLSI's example code for loading the plugin (from "VS1053b / VS1063a WAV PCM Recorder Application"). 160us*21000=3.3seconds

Questions:
1. Is there anyway to reduce the load time to less than 0.5s?
2. If not, does the VS1063 need to load a plugin for recording ogg? I think it has ogg format in ROM, but I'm not sure.

Thank you,
Ray

[pasi]

Sounds like there are extra and unnecessary waits in their implementation of SCI_WRITE(), or the SPI speed is just very slow (200kHz on average). Or maybe it doesn't use SPI hardware?

The vs1053b doesn't include Ogg Vorbis encoding in ROM, so the encoding application needs to be completely loaded.

1. You would need to dig into the SCI_WRITE implementation and see why it's so slow. If it's using SPI, what SPI clock speed have you configured?

2. Yes, vs1053a could manage without a patch for Ogg Vorbis encoding (if you hardware reset between encodings), but I would still recommend the vs1063a-encpatches patch version to fix a few bugs and give a few extra features for the encoding mode.

[nomnom-ray]

1. You would need to dig into the SCI_WRITE implementation and see why it's so slow. If it's using SPI, what SPI clock speed have you configured?

I haven't done oscilloscope analysis on the signal yet, but at least Adafruit's code for sciWrite() looks to match the requirement from VS1053b's datasheet. Adafruit's code is below (unmodified):

Code: Select all

void Adafruit_VS1053::sciWrite(uint8_t addr, uint16_t data) {
#ifdef SPI_HAS_TRANSACTION
  if (useHardwareSPI)
    SPI.beginTransaction(VS1053_CONTROL_SPI_SETTING);
#endif
  digitalWrite(_cs, LOW);
  
  spiwrite(VS1053_SCI_WRITE);
  spiwrite(addr);
  spiwrite(data >> 8);
  spiwrite(data & 0xFF);
  digitalWrite(_cs, HIGH);
#ifdef SPI_HAS_TRANSACTION
  if (useHardwareSPI)
    SPI.endTransaction();
#endif
}

Using arduino's micro() command, each spiwrite() call takes 35us, which is ~30KHz. Below is Adafruit's spiwrite() code unmodified. It uses Arduino's SPI.transfer() function. I've checked that useHardwareSPI is true.

Code: Select all

void Adafruit_VS1053::spiwrite(uint8_t *c, uint16_t num) {
  // MSB first, clock low when inactive (CPOL 0), data valid on leading edge
  // (CPHA 0) Make sure clock starts low

  if (useHardwareSPI) {

    //#if defined(ESP32)  // optimized
    //  SPI.writeBytes(c, num);
    //  return;
    //#endif

    while (num--) {
      SPI.transfer(c[0]);
      c++;
    }

  } else {
    while (num--) {
      for (int8_t i = 7; i >= 0; i--) {
        *clkportreg &= ~clkpin;
        if (c[0] & (1 << i)) {
          *mosiportreg |= mosipin;
        } else {
          *mosiportreg &= ~mosipin;
        }
        *clkportreg |= clkpin;
      }
      *clkportreg &= ~clkpin; // Make sure clock ends low

      c++;
    }
  }
}

Adafruit's VS1053 library uses 8MHz for data and 250KHz for control on the SPI. Code below:

Code: Select all

#define VS1053_CONTROL_SPI_SETTING                                             \
  SPISettings(250000, MSBFIRST, SPI_MODE0) //!< VS1053 SPI control settings
#define VS1053_DATA_SPI_SETTING                                                \
  SPISettings(8000000, MSBFIRST, SPI_MODE0) //!< VS1053 SPI data settings

I've tried to play around with the SPIsettings(). it turns out that increasing the 250KHz to 1MHz reduces the loading time from 3.3s to 1.3s.

What is VS1053b's recommended SPIsetting? The Feather M0 microcontroller uses a 32MHz crystal.

Does you see any problem using SPI.transfer()? Would DMA help? I would rather stay with VS1053b (migrating to another chip would be the last resort).

Thank you,
Ray

[pasi]

After reset vs1053b SCI reads can be perform at 12.288MHz/7 = 1.755MHz and writes to SCI or SDI at 12.288MHz/4 = 3.072MHz .

After you've written SCI_CLOCKF, the max speed will depend on the clock multiplier (CLKI/7 and CLKI/4), so if you can increase the SPI speed further, it should shorten the upload time considerably. After that, maybe you can get a little extra by trying to streamline the routines to have less overhead.

[nomnom-ray]

...so if you can increase the SPI speed further, it should shorten the upload time considerably.

There is a problem with blindly increasing the SPI speed: the recording becomes distorted with all noise (maybe it's clipping due to some kind of gain state accidentally increased too high). In any case, only uploading the .plg with SPI speed of 250KHz leads to acceptable recording.

is there any significance to the 250KHz number or is it coincidence?

[pasi]

Are you writing SCI_CLOCKF before increasing the clock and uploading the patch? (You may need to wait a bit for the clock actually to be changed, then change the SPI speed.)

Is the SPI used for your storage as well?

Have you tried increasing the SPI speed for the duration of the upload and restoring it to the 250kHz afterwards?

[nomnom-ray]

tried increasing the SPI speed for the duration of the upload and restoring it to the 250kHz afterwards

That worked! Sorry for the very delayed reply. Below is the solution:

Code: Select all

void Adafruit_VS1053::sciWritePatch(uint8_t addr, uint16_t data) {
#ifdef SPI_HAS_TRANSACTION
  if (useHardwareSPI)
    SPI.beginTransaction(VS1053_CONTROL_PATCH_SPI_SETTING);
#endif
	//unmodified code 

VS1053_CONTROL_PATCH_SPI_SETTING is only used for applying the patch. It's made to be 8MHz instead of 250KHz. The audio comes out great. The time to load the patch is 0.6 seconds instead of 4 seconds.


Follow-up request:

I want to reduce the time even further by using multiple sciWrite, but I've had no success. Below is the code for single sciWrite. Could you please advise on how it could be modified to support multiple sciWrite?

Code: Select all

void Adafruit_VS1053::applyPatch(const uint16_t *patch, uint16_t patchsize) {
  uint16_t i = 0;

  // Serial.print("Patch size: "); Serial.println(patchsize);
  while (i < patchsize) {
    uint16_t addr, n, val;

    addr = pgm_read_word(patch++);
    n = pgm_read_word(patch++);
    i += 2;  
  
    // Serial.println(addr, HEX);
    if (n & 0x8000U) { // RLE run, replicate n samples
      n &= 0x7FFF;
      val = pgm_read_word(patch++);
      i++;
      while (n--) {
        sciWritePatch(addr, val);
      }
    } else { // Copy run, copy n samples
      while (n--) {
        val = pgm_read_word(patch++);
        i++;
        sciWritePatch(addr, val);
      }
    }
  }
}

[pasi]

how it could be modified to support multiple sciWrite?

Code: Select all

void Adafruit_VS1053::applyPatch(const uint16_t *patch, uint16_t patchsize) {
  uint16_t i = 0;

  // Serial.print("Patch size: "); Serial.println(patchsize);
  while (i < patchsize) {
    uint16_t addr, n, val;

    addr = pgm_read_word(patch++);
    n = pgm_read_word(patch++);
    i += 2;  
  
    // Serial.println(addr, HEX);
    if (n & 0x8000U) { // RLE run, replicate n samples
      n &= 0x7FFF;
      val = pgm_read_word(patch++);
      i++;
      while (n--) {
        sciWritePatch(addr, val);
      }
    } else { // Copy run, copy n samples
      while (n--) {
        val = pgm_read_word(patch++);
        i++;
        sciWritePatch(addr, val);
      }
    }
  }
}

1. Start SCI write (xCS low, send 0x02 and register address)
2. Write data words
3. Bring xCS high.
Something like:

Code: Select all

   } else { // Copy run, copy n samples
     sciStartWrite(addr); //set xCS low, send the write command byte and address byte
      while (n--) {
        val = pgm_read_word(patch++);
        i++;
        sciContinueWrite(val); //send the 16-bit value
      }
      sciEndWrite(); // wait until SPI is idle, then bring xCS high.
    }

[nomnom-ray]

Code: Select all

    } else { // Copy run, copy n samples
      #ifdef SPI_HAS_TRANSACTION
        if (useHardwareSPI)
          SPI.beginTransaction(VS1053_CONTROL_PATCH_SPI_SETTING);
      #endif
      digitalWrite(_cs, LOW);  
      spiwrite(VS1053_SCI_WRITE);
      spiwrite(addr);
      while (n--) {
          val = pgm_read_word(patch++);
          i++;
          spiwrite(val >> 8);
          spiwrite(val & 0xFF);
      }
      digitalWrite(_cs, HIGH);
      #ifdef SPI_HAS_TRANSACTION
        if (useHardwareSPI)
          SPI.endTransaction();
      #endif
    }
  }

So, The above code works.It uses the same 8MHz SPI setting on top of using continuous data write.

It now takes 0.35 seconds instead of 0.6 second.

I tried increase SPI setting to 12MHz, but the time reduction became minimal (0.33 seconds). It seems that the relationship between upload speed and SPI setting is non-linear.

If you can think of any other ways of reducing time. Please let me know. For example, can the first sciWrite be replaced with multiple sciWrite?

Code: Select all

    if (n & 0x8000U) { // RLE run, replicate n samples
      n &= 0x7FFF;
      val = pgm_read_word(patch++);
      i++;
      while (n--) {
        sciWritePatch(addr, val);
      }

Otherwise, it has been my pleasure getting help from you. Thank you very much.

[pasi]

I didn't think there are that many RLE runs, which is why I didn't address that. But yes, it can be changed to use SCI multiple write too.

Now that I think about it, in the Ogg Vorbis Encoding application you'll probably have more RLE runs than in the vs1053b patches.