Difference between revisions of "User:Andrew Hallendorff"

From Audacity Wiki
Jump to: navigation, search
Line 9: Line 9:
  
 
==The Layout==
 
==The Layout==
In the abstract this implementation can be thought of as 3 streams of data/instructions.  
+
In the abstract this implementation can be thought of as 3 streams.
  
 
* Base Indexes - 32bit integers that store both data and instructions.
 
* Base Indexes - 32bit integers that store both data and instructions.
* Data Blocks - Indexed chunks of data of a fixed size. (most likely 512 (32 bit samples) or 1024 (16 bit samples)
+
* Data Blocks - Indexed chunks of data of a fixed size. Most likely 512 (32 bit samples) or 1024 (16 bit samples)
* Events (instructions) - Indexed list of variable size and scope of actors.
+
* Events (instructions) - Indexed list actions. Size and scope of these actors would be variable.
  
Within these page table entries the data could be replaced with negative numbers to index a certain event. The even would preserve the removed page entry while linking to a operation to be preformed upon the stream. The general concept would be a memory model where samples could be directly accessed via a page table rather than a linked list.  
+
=== Interactions ===
 +
In its simplest form, to just play data, the processing agent would walk the Base Indexes and move the Data Blocks into the play buffers. A linear stream of data would be indexed by a list of incremental integers form [0..N] each pointing to a Data Block sized chunk of data in order.
  
 +
The Data Blocks could be stored in any order and indexed multiple times providing a functional sequencing of audio with a resolution of rate/blocksize. (512/48k = ~10ns) Sequencing at a greater level would require events.
 +
 +
Data Blocks would be further paged in groups of 512 to fit the general page table size of most computers and allow for them to be read and written from disk as necessary.
 +
 +
How events interact with the streams. Within the stream of Base Indexes a negative number would correspond to a certain event. The event would preserve the removed page entry while linking to a operation to be preformed upon the stream. This maintains the original data while allowing almost infinite customization. (2^31 events).
 +
 +
=== Example ===
 +
 +
A simple cut
 +
 +
{| class="wikitable" id="Example" legend="Example" style="background:#EEEEEE; padding:10px"
 +
|-valign=top align="left"
 +
! Bin !! 0 !! 1 !! 2 !! 3 !! 4 !! 5
 +
|-valign=top align="center"
 +
| Indexes Before Cut 3 and 4
 +
| 0
 +
| 1
 +
| 2
 +
| 3
 +
| 4
 +
| 5
 +
|-valign=top align="center"
 +
| Indexes After Cut 3 and 4
 +
| 0
 +
| 1
 +
| 2
 +
| -1
 +
| 4
 +
| 5
 +
|}
 +
 +
Event 1 (-1) = Hold saved data 3 jump to bin 5
 +
 +
The processor would walk the data. For 0..2 it would just be copy block and play. When it reaches the 3rd bin it would find a negative number and thus look up event 1. Where it was told to jump to bin 5.
  
 
[[Category:Feature Planning]]
 
[[Category:Feature Planning]]

Revision as of 23:31, 12 November 2014

Proposal pages help us get from feature requests into actual plans. This is related to both Real Time Adjustment and Threading and Acceleration.
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.


  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.

Proposed Feature: Page Tabled Memory and Event Layout

To facilitate the environment that would be conducive to both multi-threading and non-destructive processing.

Developer/QA/Programmer backing

  • Andrew Hallendorff

The Layout

In the abstract this implementation can be thought of as 3 streams.

  • Base Indexes - 32bit integers that store both data and instructions.
  • Data Blocks - Indexed chunks of data of a fixed size. Most likely 512 (32 bit samples) or 1024 (16 bit samples)
  • Events (instructions) - Indexed list actions. Size and scope of these actors would be variable.

Interactions

In its simplest form, to just play data, the processing agent would walk the Base Indexes and move the Data Blocks into the play buffers. A linear stream of data would be indexed by a list of incremental integers form [0..N] each pointing to a Data Block sized chunk of data in order.

The Data Blocks could be stored in any order and indexed multiple times providing a functional sequencing of audio with a resolution of rate/blocksize. (512/48k = ~10ns) Sequencing at a greater level would require events.

Data Blocks would be further paged in groups of 512 to fit the general page table size of most computers and allow for them to be read and written from disk as necessary.

How events interact with the streams. Within the stream of Base Indexes a negative number would correspond to a certain event. The event would preserve the removed page entry while linking to a operation to be preformed upon the stream. This maintains the original data while allowing almost infinite customization. (2^31 events).

Example

A simple cut

Bin 0 1 2 3 4 5
Indexes Before Cut 3 and 4 0 1 2 3 4 5
Indexes After Cut 3 and 4 0 1 2 -1 4 5

Event 1 (-1) = Hold saved data 3 jump to bin 5

The processor would walk the data. For 0..2 it would just be copy block and play. When it reaches the 3rd bin it would find a negative number and thus look up event 1. Where it was told to jump to bin 5.