User:James/Audio Architecture Project

From Audacity Wiki
Jump to: navigation, search
The Audio Architecture Project is a project to design and document updates to the Audio architecture that will support Audacity going forward. The documentation will include a dynamic diagram, and explanations for the design decisions, maintained in wiki. Changes in code will be made to clarify the architecture and its function.

This will:

  • Help us extend Play-At-Speed to include loop play with real-time variable selection, cut preview and other real time features.
  • Lead to clearer cleaner code, especially the core code, actually in Audacity.
  • Make it easier for new developers to get involved.

This is essentially a documentation project, aimed at making it easier for new and existing developers to work on the core code. The code changes are mainly ones of presentation, paying off technical debt by making the existing code much clearer.




Origin

This project is a focused rethink of User:James/Documentation2_Project, to focus on the part that has the biggest impact.

  • It is partly inspired by Bug 1932, which entailed working through code which has accumulated over time, and needs tidying.
  • It is partly inspired by this diagram from The architecture of Open Source which now needs extension to show scrubbing and MIDI, and could benefit from an updated more interactive version.

AudacityAudioPaths.png


  • It is also inspired by the new possibilities of incorporating interactive diagrams directly in Wiki - see for example the clickable diagram and this wiki text processing. This means we can mix interactive diagrams and collaboratively maintained text explanations.


Audience

The flexibility of the diagrams will mean that the documentation is:

  • Suitable for people completely new to Audacity code.
  • Suitable for people experienced in the code.


Strategy

  • Stage 1: Hand drawn (non interactive) diagrams of current and improved architecture and accompanying text. Tidying (but not change of function) on existing code.
  • Stage 2: Interactive diagrams that are more flexible. We can choose options, show and hide details, and can link to actual code.
  • Stage 3: Make some of the change of function to existing code, for example offloading repainting to worker threads so that the GUI is always responsive. Precise agreed details TBD.


Details

The key to understanding the multithreaded architecture is to understand the impedance mismatches between different tasks. Some tasks are fine grained and regular. Other tasks have large chunks and are 'bursty'.

  • The interactive diagrams will indicate volumes of data and frequencies, under different scenarios.

It is quite possible I will get some things wrong in my explanation. This is why it is valuable to have this as a wiki based project.

  • The text will be wiki editable, and so will many aspects of the diagrams. This makes it (a) collaborative and (b) makes it possible for developers to present diagramatic proposals for architectural changes.

The diagram in the AOSA book paints broad sweeps. It does not dig deeper into the actual functions that do the work.

  • The diagrams will have hover text and associated details. So for example, for each arrow you can easily find the function(s) that do the work in those arrows.