-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
load bfin audio buffers via SPI #62
Comments
currently reading raw audio files as parameter changes to SDRAM, it works but it's kinda slow, about 4k/second I think. I'm wondering if it is possible to temporarily (during startup) increase the speed of the parameter changes? Or does this need another solution altogether? |
not sure what you';re doing exactly (can you link to code?) but i wouldn't use the param change framework per se. i would extend the SPI protocol to allow arbitrarily sized block transfers and define a separate command in the protocol header: it is theoretically possible to change the SPI transfer block size on the fly, though we are not doing that right now. at one point in early development we did switch bfin SPI modes, from master to slave, during codec intialization, and it worked fine. i would do all large transfers at a specific stage in module initialization, before processing audio. avr32 spi setup: https://github.com/tehn/aleph/blob/master/avr32_lib/src/init.c#L256-L257 ) bfin spi setup: https://github.com/electropourlaction/aleph/blob/master/bfin_lib/src/init.c#L99 |
to clarify, i would make the process something like:
then the bfin RX state machine can be made pretty efficient. |
I have tried using a separate command, it failed however on writing the data to the SDRAM buffer. This is the current solution using parameter changes, see custom callback: https://github.com/electropourlaction/aleph/blob/dev/apps/prgm/src/app_timers.c#L99-116 The speed is set to 1: https://github.com/electropourlaction/aleph/blob/dev/apps/prgm/src/app_timers.c#L121 |
i'm still wondering why this didn't work for you. you say it failed on writing data to the SDRAM buffer - how so? SDRAM writes are a little slow, but shouldn't be so slow that it can't keep up with the avr32. i just think it should be more efficient to send the audio bytes directly rather than wrapping each one in a param change. (or rahter, two param changes.) |
I got the data thru the spi process with a separate command, did a test by sending it to out[0] directly in the spi process (it came out distorted so probably not in sync with the audio processing, but something came thru at least), where I failed was at storing the data at a specific address in SDRAM, I´m just learning these things so I haven't looked at if there could be some kind of interrupt or pin state requirement in this type of command, or maybe I did not get the addressing part right... |
managed to move sample transfer outside of the timer/parameter loop now, just don't know what I was doing a year ago :) also started to look at the inevitable next step, stream/load with tiny buffers from file to SDRAM. not aiming at audio rate streaming but to load up to 64MB samples, and to switch patterns faster by loading them "in the background" instead of stopping up to handle memory allocation etc. (atm first step on a new pattern will get a short, sometimes jon bonham-ish groovy, delay when the external clock is over ~120 bpm). starting up by looking at the newly merged monome/avr32lib. |
first attempt without a temporary buffer, it's working but not as fast as I'm hoping for, will keep digging for ways to improve the speed. void files_load_sample(u8 n) {
} |
test w buffer. 28kb/s void files_load_sample(u8 n) {
} |
test w/o buffer, tweaked. 70kb/s. void files_load_sample(u8 n) {
} int bfin_sample_transfer(unsigned long sector, unsigned long bytes) {
} |
have tried setting the spi .trans_delay down to 1 instead of 20, seems to be working, what was the purpose of setting it so high? too limit it to one transfer per sample? edit. will dig some more when time permits and try to get bi-directional transfer going, the goal is realtime bounce to card (not sure if I'm gonna succeed though!). some thoughts so far. |
extend SPI protocol for reading audio wavefiles to bfin SDRAM.
The text was updated successfully, but these errors were encountered: