Questions about Lich capabilities + Owl Digital mk2 Rev7 Specs (gen~ in mind)

OWL Lich
#1

Hi, wondering about the specs listed in the Lich Manual and how they translate to layman terms:

48kHz 24-bit stereo audio

  • would setting the dev machine to these settings insure identical sound playback of gen patches? I notice some pitch differences when checking in MaxMsp and the website with desktop audio at 48khz 16bit - perhaps this is because the desktop audio isn’t at 24bit?

3500 operations per sample
I assume this is the maximum allowed operations before there is sound degrading? Seems pretty high and not sure how to measure this other than comparing cpu usage on desktop vs data from the compiler with Lich connected (for example 5% on desktop would mean 30% on Lich or something)

STM32F427 180MHz, 256Kb RAM, 1Mb Flash
8Mb SDRAM
8Mb NOR Flash
The most confusing part for me - the STM memory vs the SDRAM vs NOR Flash - what it is used for, what is stored there, is it wiped on reboot, how to utlize which with Gen~ (if possible), how it translates to number of samples that can be used as buffers - any pointers appreciated!
Assumptions

  • onboard 256kb RAM, 1mb Flash are used for OWL firmware and operations
  • 8mb SDRAM can be used for sampling buffers in each patch, cleared on reboot/patch load. Unprecise estimate is this is 55 seconds of audio (* 48000) = 2640000 samples that can be used for all the buffer objects. 24bit means there is a resolution of 0-16,777,216 for a value in a sample? 16+ million values between -1 and 1? or any range? Or is that something else since we are working with 32bit floats, or is it corelated.
  • 8mb NOR used for patch storage - does that mean we can include data with a patch to dump into the Ram or even playback from the storage?

Integrated DSP, FPU, DMA
are these all on the STM or are there other chips responsible? What sort of information on them can we learn to utilize in patches?

#2

This is specification for MCU used on current OWL board and some additional chips that are also a part of it. 3500 operations may be not the most precise choice of words - this is number of MCU clock samples available for 1 sample of audio. But many (most?) operations take more than 1 clock sample, there is additional latency from accessing data in flash or SDRAM, etc. It’s similar MCU to what is used in MI Clouds, for example. But there are extra chips that make it more capable overall.

Regarding SDRAM usage, your calculation is wrong, because gen~ would be using 32 bit float buffers. You can use up to 43 sec buffer, but there are other possibilities to extend that - using 16 bit integer buffers if you really need would double buffer length without noticeable loss in quality.

SPI NOR chip was added as potential stretch goal on kickstarter. It wasn’t reached after all, but Martin still gifted us with that, except that it’s not supported by firmware yet. I’ve actually started working on adding it, so I can tell that next big update (after USB audio) would be reading from flash storage, then it would be support for SPI NOR. This would allow you loading wavetables, short samples or any other data that you want to share between patches.

This microcontroller supports different memories - SRAM is its internal volatile memory, has no (or minimal) access latency for access and is limited in amount. SDRAM is external volatile memory (8MB chip) with higher access time. Flash is internal persistent memory (1 MB, but 384kb is for firmware/bootloader) on which you store patches - and soon we’ll be documenting reading/writing user data. It’s also possible to address data stored on it directly, the same way as you would do for data in RAM. And there’s extra chip of 8MB NOR flash from which you can copy data to memory (but can’t address directly).

1 Like
#3

really insightful thank you!

sort of ontopic as I was getting carried away -
when the web compiler shows CPU and Memory usage - what does “memory 8000” mean on the Lich - what would be the maximum we should stay around on a running patch?

With current gen~ approach to filling the databuffer, it seems doing it in a for loop is pretty safe (poking stuff at the same time will crash Lich, so you have to time it right per buffer), and I wonder if loading a giant wave in parts is feasable. Pushing the boundaries of inefficiency!

with the quick lite version of the wavetable patch I am seeing:

CPU: 61% Memory: 4680

MESSAGE:
Storage used 98468
deleted 24648
free 425820
total 524288

Hopefully the CPU doesn’t need to go up per buffer (if it isn’t being "peek"ed by the gen patch) - right now its 1 phasor running 3 wave objects from 3 different data buffers of 253 samples each (759 together) - and that is 4680 BYTES?

note sure what exactly the other things mean - like deleted? that is to be over written by new patches? is that ram? Thanks for understanding the confusion!

#4

Memory is SDRAM, used for dynamic allocation - 8Mb max.

Storage is internal flash. “Deleted” is space used by deleted patches. To minimize amount of writes to the same location, deleting a patch only marks it as deleted by writing a single byte. It will truly be erased when defragmentation procedure is running if you’re out of space or if you format the patch storage. This extends flash storage lifespan, because it can perform limited number of writes before wearing out - many thousands writes, so we just have to make sure not to write to the same place every time.

1 Like
#5

ah wow so i was already at 4.6mb?

#6

Heya - I am still unclear at what those numbers on the site correlate to

Storage Used/deleted/free/total - is in bytes?
“Memory” next to CPU is in KB?

#7

This is the important bit. It means you are using 61% of available CPU cycles and 4680 bytes of heap memory. You have at least 8Mb of heap available, i.e. 810241024 bytes. So plenty of room to grow there!

This is probably only supposed to show up on the Device page. It’s a bit of debug information really, telling you how much of the patch storage memory you are using. The ‘deleted’ space will be recycled when you run out of free space to store a new patch.

It might seem a bit strange, but basically if you store a patch to a slot that is already in use, instead of deleting it and reusing that space we simply mark it as ‘deleted’. Then when one day you run out of free space we collect all the deleted and used sectors, defrag the lot and write it out again. It means that we don’t have to write to the same sectors all the time, and spreading out the write cycles across the flash memory makes it last longer. It is a form of wear leveling, same principle as on an SSD drive.

2 Likes
#8

That is super. The fact the memory is in bytes is awesome - tons of freedom