Ogg Encoder Plugin upload behaviour

Writing software for systems that use VLSI Solution's devices as slave codecs to a host microcontroller.
Post Reply
quickshat
User
Posts: 9
Joined: Fri 2016-07-22 11:21

Ogg Encoder Plugin upload behaviour

Post by quickshat » Mon 2018-11-12 14:17

Hi its me again.. :D

The audio recording with the OggEncoder plugin works somehow fine except the fact that i have to wait like 7seconds+ to initiate a recording and i think this isn't the way it should be.

My LoadPlugin method does nth. more than executing the unpacking algorithm and writing uint by uint to the VS1053. In the whole init procedure i measured nearly every step and came to the conclusion that the most time expensive part is the uploading of the plg file.

Now i was thinking about executing the unpacking algorithm and instead of writing bytes to the device directly i am going to write them to a file. Now i got the uncompressed file which i might be able to upload in a single step to reduce uploading time overhead.

Am i right so far ?

If you have other suggestions or experience with plugin loading it would be nice if you could tell me.
My SPI interface is currently at 10MHz speed.

Additionally an excerpt of the old upload method without the already uncompressed file:

Code: Select all

private ushort LoadPlugin(string plugname, SPI.Configuration config = null)
        {
            string filename = Storage.ResolvePath(plugname);
            using (FileStream f = new FileStream(filename, FileMode.Open))
            {
                BinaryReader plugin = new BinaryReader(f);

                if (plugin.ReadChar() != 'P' || plugin.ReadChar() != '&' || plugin.ReadChar() != 'H')
                    throw new Exception("Bad image format");

                FlowTimer.NewWaypoint("Uploading plugin");

                while (plugin.BaseStream.Position < plugin.BaseStream.Length)
                {
                    ushort[] offsets = {(ushort) 0x8000UL, 0x0, (ushort) 0x4000UL};

                    ushort type = plugin.ReadByte();
                    if (type >= 4) throw new Exception("Invalid plugin");

                    ushort len = plugin.ReadByte();
                    len <<= 8;
                    len |= (ushort) (plugin.ReadByte() & 0XFE);

                    ushort addr = plugin.ReadByte();
                    addr <<= 8;
                    addr |= plugin.ReadByte();

                    if (type == 3)
                    {
                        Debug.Print("[AudioModule] Successfully loaded a plugin with start address: 0x" +
                                    addr.ToString("X"));
                        return addr;
                    }

                    SciWrite(SciRegisters.WramAddr, (ushort) (addr + offsets[type]), config);

                    do
                    {
                        ushort data = plugin.ReadByte();
                        data <<= 8;
                        data |= plugin.ReadByte();
                        SciWrite(SciRegisters.Wram, data, config);

                    } while ((len -= 2) != 0);
                }
                throw new Exception("Invalid plugin");
            }
        }

User avatar
Henrik
VLSI Staff
Posts: 1107
Joined: Tue 2010-06-22 14:10

Re: Ogg Encoder Plugin upload behaviour

Post by Henrik » Mon 2018-11-12 15:42

Hello!

The .img files containing the VS1053 Ogg Vorbis encoder plugin are approximately 40 KiB of size. That means that sending the encoder through SPI at 10 Mbit/s will take 64 milliseconds even taking about the 100% SPI overhead you get if you don't use SCI Multiple Write. If using SCI Multiple Write, shave half of the time to 32 ms.

The .plg plugin files are approximately 14 KiW, or 28 KiB of size. Sending a plugin at 10 Mbit/s SPI speed takes at minimum 44 milliseconds, perhaps slightly more when you observe DREQ properly. Again, with SCI Multiple Write you can make this even faster, but usually even the normal speed is not a problem.

If sending a plugin to VS1053 takes you 7 seconds, that means that your code is about 100 times slower than what it could ideally be. So there is a performance issue somewhere. To see where the issue is, I'd do classical "oscilloscope debugging": Take a microcontroller pin that is more or less free, then turn the pin high before the part that you want to measure and low after. By checking the different parts of code like this you will end up seeing which part of your code is eating all the time. Because the code you quoted is very short, I'd start by checking the speeds of ReadChar()/ReadByte() and SciWrite() in the innermost do/while loop.

Kind regards,
- Henrik
Good signatures never die. They just fade away.

Post Reply