Skip to content
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

blackfin control rate #33

Open
catfact opened this issue Aug 7, 2013 · 4 comments
Open

blackfin control rate #33

catfact opened this issue Aug 7, 2013 · 4 comments

Comments

@catfact
Copy link
Collaborator

catfact commented Aug 7, 2013

we should be able to drastically improve blackfin performance with a well-considered control rate implementation.
will also let us get away with more in the numerical-precision department when e.g. applying control-rate filters.

@catfact
Copy link
Collaborator Author

catfact commented Aug 10, 2013

implemented in a basic way.
( 14683da )
could be a more elegant queue structure.

@catfact catfact closed this as completed Aug 10, 2013
@catfact
Copy link
Collaborator Author

catfact commented Nov 14, 2013

reopening this. never had time to do a satisfactory implementation and reverted to direct-set from the spi rx isr (bad). still storing global copy of module parameter data, with dirty flag, which is burning resources but will probably be useful.

aleph/dsp/module.h
aleph/bfin_lib/src/spi.c

@catfact catfact reopened this Nov 14, 2013
@electropourlaction
Copy link

not super sure this is related but I'm working on a separate spi event message, the idea is to send just an empty message which calls a module_event(), typically some kind of trigger or next step happening, this part is done. Hoping to add a filter somewhere in the spi process to so that events always are handled before parameter changes.

update with added links to code...

creating an event from an incoming cv trig,
https://github.com/electropourlaction/aleph/blob/dev/apps/prgm/src/handler.c#L32-34

spi transfer, ending with a call to module_set_event()
https://github.com/electropourlaction/aleph/blob/dev/avr32_lib/src/bfin.h#L76
https://github.com/electropourlaction/aleph/blob/dev/avr32_lib/src/bfin.c#L346-351
https://github.com/electropourlaction/aleph/blob/dev/common/protocol.h#L28
https://github.com/electropourlaction/aleph/blob/dev/bfin_lib/src/spi.c#L89-92
https://github.com/electropourlaction/aleph/blob/dev/dsp/module.h#L58

stuff happens, module specific implementation,
https://github.com/electropourlaction/aleph/blob/dev/modules/prgm/prgm.c#L401-418

@catfact
Copy link
Collaborator Author

catfact commented Jul 12, 2015

i'm referring to a broader change in the architecture wherein control changes would be processed at a fixed rate on the blackfin, slower than the audio rate, instead of directly from the SPI RX interrupt.

our current strategy is to use the bfin_ready GPIO to hold off sending from the avr32 until bfin is not currently processing an audio frame, and assuming that this means it has time to process an SPI transaction before the next audio frame. seems to work pretty well...

but i'm working on restructuring the whole mess to something like this:

  • maintain an 8- or 16-frame sample buffer for audio I/O
  • read and write to this buffer on audio ISR
  • main loop processes the whole buffer (instead of a single frame)

a complementary step would be to maintain a similar buffer for control changes, push param changes / events in SPI ISR, and process them in main loop once per audio block.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants