[Audacity-devel] Questions about Audacity Architecture
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: freddyjohn <fre...@pr...> - 2021-04-22 17:34:51
|
Hello its me again I have three questions for my open source DAW for android. If this is not the place to ask these questions I apologize and would love direction on a community that may be able to answer them. In my experience, Stack Overflow and blogs like it is not that place. I of course have tried and implemented my own solutions but I want to hear from you guys. 1.) what are the data structures used to efficiently handle edits to audio? is it a b-tree, do you use a piece table, what is the structure inside those XML files? what I've tried: I have found a solution using piece table. I keep track of all the edits in one file and when the user is finished I serialize the java object and append it to the end of the file along with integer that describes the byte length of the java object so that it can be de-serialized during another session acting as a project file. I have spent some time looking through audacity source code and reading audacity blogs but I am still not sure exactly what data structure is used. This was an excellent read -> http://www.aosabook.org/en/audacity.html 2.)how do we handle modulations now that the file is in blocks? did you have to worry about the continuity of the LFO for a phaser about these blocks for example? what I've tried: I can see an easy solution to this by calculating the leftover phase and offsetting the next modulation wave by this leftover phase. but for an echo it seems you would need a completely different solution. 3.)Another thing I am struggling with is displaying audio efficiently. what I've tried: on Android we have limited heap memory so I cannot just go and ask for huge Bitmap allocation I need to keep space open for bringing byte[] into program memory to perform modulations so I just ask for a Bitmap that is the h,w of the screen then I scale the audio into this space like this let, screen width of fixed sized = w_N amount of samples = s_N then the equation to scale s within w can be found via s_N ∑ i * (w_N/s_N) i=0 and in order to translate the selection on the screen back into byte land we can use this equation w_i * (s_N/w_N) = s_i for example, a screen of 500px, an audio file of 1000 bytes and a selection within 500px of 500 500*1000/500=1000. I also ensure to never select an odd byte depending on the selected encoding as this creates an extremely unfavorable offset that causes the audio byte stream to not decode correctly. Of course this is O(n) and not very efficient at all. The time it takes to display the file will grow with the length of the file which is very unfavorable to the user. I understand Audacity uses summary information of the audio for parts of its display but I am having a difficult time understanding how we can translate a selection within this summary information to actual file byte locations. It seems that these problems are linked and after spending some time trying to tackle them myself I would really love to hear from the Audacity Team about how they found solutions to these problems. Sent with [ProtonMail](https://protonmail.com) Secure Email. |