GAL (Generic Audio Library) based on GIL
I am looking into the possibility of developing a library based on the same concepts and a similar interface to Boost.GIL call Boost.GAL. The idea is simply to define something very similar to GIL but for audio processing instead of image processing. Most of the concepts in GIL map almost 1 to 1 to audio processing as well. What are peoples thoughts on such a project? Is there anything in Boost.GIL that we have learn't from that should be done differently? --- Basic Premise --- The base concepts for GAL are described below and shown are the direct equivalents in the GIL library: * GAL.Sample ~= GIL.Channel Represents the amplitude of a single audio sample (float32, int16, ...) * GAL.SampleTime ~= GIL.Point Identifies the "time" a sample was taken (in units of the SampleRate) * GAL.Channel ~= GIL.Colour Identifies an audio channel location (FRONT_LEFT, or FRONT_RIGHT might be a channel for example) * GAL.ChannelMapping ~= GIL.Colour-space Maps channels to specific layout in memory (offset 0 is FRONT_LEFT, ...) * GAL.Frame ~= GIL.Pixel Identifies a single time slice (multiple channels for single sample point in time) * GAL.Block ~= GIL.Image Identifies a 1D sequence of Frame's * GAL.SampleRate ~= GIL.PPI I don't think GIL has this concept at the moment, but would be similar to Pixels Per Inch in the image world * GAL.Layout ~= GIL.?? This is the same in GIL and GAL the memory layout can be interleaved or not (planar for GIL) * GAL.Format ~= GIL.?? I don't think GIL has this concept at the moment but it represents the format of data without actually storing any data. It contains: - Sample type - ChannelMapping (implicitly identifies count of channels) - SampleRate - Layout
2013/4/29 Brendon Costa <brendon.j.costa@gmail.com>:
I am looking into the possibility of developing a library based on the same concepts and a similar interface to Boost.GIL call Boost.GAL.
The idea is simply to define something very similar to GIL but for audio processing instead of image processing. Most of the concepts in GIL map almost 1 to 1 to audio processing as well.
What are peoples thoughts on such a project?
I was dreaming of such library for a long time, it would be great to have it in Boost. -- Best regards, Antony Polukhin
On 29/04/13 14:24, Brendon Costa wrote:
I am looking into the possibility of developing a library based on the same concepts and a similar interface to Boost.GIL call Boost.GAL.
The idea is simply to define something very similar to GIL but for audio processing instead of image processing. Most of the concepts in GIL map almost 1 to 1 to audio processing as well.
What are peoples thoughts on such a project?
A lot of audio processing happens in the frequency domain. How does your library address this?
On Tuesday, 30 April 2013, Mathias Gaunard wrote:
A lot of audio processing happens in the frequency domain.
How does your library address this?
Yes handling domains other than the time domain is very important and I will think more about this and make sure it is supported by the library. I have not yet looked yet into how GIL handles different domains or even if it does. The library right now is just a concept and I am starting to flesh the idea out some more. I have been thinking about representation in different domains but have not yet decided which way to go. My plan is to work on various use cases of the library and compare different designs before I decide. Conceptually I like the idea of the domain being encoded in the data format type but I have not really explored the consequences of this yet. The extra dimension of Domain if we add it to the data format type will have no effect on the layout in memory unlike all other parameters in the type which is one reason against doing this, but I can see places where it is useful to know so the algorithms can be defined in the correct way. So it needs some more thought. Additionally the library will provide a few basic common algorithms and may be expanded over time. A fft will certainly be one of those algorithms, but primarily GIL and GAL initially deal with efficient use/access of variable memory layouts such that algorithms can be defined to operate on them generically and efficiently.
I would also be very pleased to see a generic audio processing library in boost and would certainly make use of it if one existed. Is the proposed library meant to be useable in real-time applications? On Mon, Apr 29, 2013 at 9:45 PM, Brendon Costa <brendon.j.costa@gmail.com>wrote:
On Tuesday, 30 April 2013, Mathias Gaunard wrote:
A lot of audio processing happens in the frequency domain.
How does your library address this?
Yes handling domains other than the time domain is very important and I will think more about this and make sure it is supported by the library. I have not yet looked yet into how GIL handles different domains or even if it does.
The library right now is just a concept and I am starting to flesh the idea out some more. I have been thinking about representation in different domains but have not yet decided which way to go.
My plan is to work on various use cases of the library and compare different designs before I decide.
Conceptually I like the idea of the domain being encoded in the data format type but I have not really explored the consequences of this yet.
The extra dimension of Domain if we add it to the data format type will have no effect on the layout in memory unlike all other parameters in the type which is one reason against doing this, but I can see places where it is useful to know so the algorithms can be defined in the correct way. So it needs some more thought.
Additionally the library will provide a few basic common algorithms and may be expanded over time. A fft will certainly be one of those algorithms, but primarily GIL and GAL initially deal with efficient use/access of variable memory layouts such that algorithms can be defined to operate on them generically and efficiently.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tuesday, 30 April 2013, Rich E wrote:
I would also be very pleased to see a generic audio processing library in boost and would certainly make use of it if one existed. Is the proposed library meant to be useable in real-time applications?
I would expect so and will endeavor to achieve this as I do understand it is often important in the audio space. I have not myself had to write any hard-realtime applications before so may need some input from others with more experience on this, but as I understand it is a matter of having bounded processing time so taking into account things like not using locks, allowing pre-allocation of memory etc.
Excellent. Yes those are essentially the big points, although I would add that sharing memory can also be a good plan, at least in a processing loop. Processing block size is also of concern, as the smaller it can be, the lower the latency (between 64 and 512 samples per block is the range most try to hit). On Mon, Apr 29, 2013 at 11:34 PM, Brendon Costa <brendon.j.costa@gmail.com>wrote:
On Tuesday, 30 April 2013, Rich E wrote:
I would also be very pleased to see a generic audio processing library in boost and would certainly make use of it if one existed. Is the proposed library meant to be useable in real-time applications?
I would expect so and will endeavor to achieve this as I do understand it is often important in the audio space.
I have not myself had to write any hard-realtime applications before so may need some input from others with more experience on this, but as I understand it is a matter of having bounded processing time so taking into account things like not using locks, allowing pre-allocation of memory etc.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Antony Polukhin -
Brendon Costa -
Mathias Gaunard -
Rich E