[julia-users] [ANN] JuliaAudio Organization and a slew of packages

[Spencer Russell]

Hey there, Julians.

So AudioIO has been languishing for some time now, and I’ve been busily working 
away at the next generation. One of the issues with AudioIO is that it was a 
lot to swallow if you just wanted to play or record some audio. I’ve been 
focusing on getting the fundamental APIs right, so that the fancy stuff can be 
built on top.

There’s a new JuliaAudio  organization and 5 
shiny new packages. They’re still pretty young, but most of them have good test 
coverage. I’m planning on registering to METADATA soon, but I wanted to solicit 
some feedback first.

SampleTypes.jl  is the most 
important as it defines the architecture that glues together the rest of the 
packages. It defines a set of stream and buffer types that should make it easy 
to move sampled data around. It’s called SampleTypes instead of AudioTypes 
because it should be useful for any sort of regularly-sampled, multi-channel 
data (e.g. complex samples from an SDR, multi-channel EEG, etc.). The types are 
sample-rate aware, and the samplerate can be stored in real units using 
SIUnits.jl. That allows cool features like reading in data using seconds 
instead of samples. 

Part of the idea with SampleTypes is to make it really easy to plug in a 
streaming audio backend, for instance SampleTypes handles conversion between 
formats, channel counts, and sample rates (currently just linear 
interpolation), so the underlying device libraries don’t have to. SampleBuf 
(the buffer type) is an AbstractArray, and it should be pretty drop-in 
replaceable to normal Arrays, but with extra goodies. If there are cases where 
it doesn’t act like an Array please file an Issue.

LibSndFile.jl  and PortAudio.jl 
 used to be part of AudioIO, but 
are now separate packages. They wrap well-established cross-platform C 
libraries for interacting with files and real-time audio devices, respectively.

LibSndFile has been designed to work with FileIO, so loading a file is as easy 
at `load(“myfile.wav”)` and it will figure out the format from the extension 
and magic bytes in the file header.

PortAudio.jl has been massively simplified from what was in AudioIO. Test 
coverage is at 95%, but because PortAudio doesn’t provide a way to simulate 
input the tests aren’t very strong. They also don’t run on Travis.

JACKAudio.jl  is a wrapper for 
libjack, a great audio routing tool designed for low-latency, pro audio 
applications. Unfortunately we’re not yet at the point where we can get super 
low latency from Julia, but it’s working pretty well now and I think there’s 
still room to tune it for better performance.

RingBuffers.jl  is a small 
utility package that provides the RingBuffer type. It’s a fixed-size 
multi-channel circular ringbuffer with configurable overflow/underflow 
behavior. It uses normal Arrays and is not specific to this architecture, 
except that is assumes each channel of data is a column of a 2D Array.

Here’s a screenshot from the PortAudio README that gives a good flavor for the 
sort of things these packages can do together:



Please kick the tires and let me know what doesn’t work or is confusing. Also, 
if you maintain an audio-related package and want to plug into this 
architecture, I’d be happy to start growing the JuliaAudio organization both in 
maintainers and packages.

-s

Re: [julia-users] [ANN] JuliaAudio Organization and a slew of packages

[Stefan Karpinski]

This is very cool. I've been meaning to try out some audio programming in
Julia but now I really must..

On Sun, Mar 20, 2016 at 5:31 AM, Spencer Russell  wrote:

> Hey there, Julians.
>
> So AudioIO has been languishing for some time now, and I’ve been busily
> working away at the next generation. One of the issues with AudioIO is that
> it was a lot to swallow if you just wanted to play or record some audio.
> I’ve been focusing on getting the fundamental APIs right, so that the fancy
> stuff can be built on top.
>
> There’s a new JuliaAudio  organization and
> 5 shiny new packages. They’re still pretty young, but most of them have
> good test coverage. I’m planning on registering to METADATA soon, but I
> wanted to solicit some feedback first.
>
> SampleTypes.jl  is the most
> important as it defines the architecture that glues together the rest of
> the packages. It defines a set of stream and buffer types that should make
> it easy to move sampled data around. It’s called SampleTypes instead of
> AudioTypes because it should be useful for any sort of regularly-sampled,
> multi-channel data (e.g. complex samples from an SDR, multi-channel EEG,
> etc.). The types are sample-rate aware, and the samplerate can be stored in
> real units using SIUnits.jl. That allows cool features like reading in data
> using seconds instead of samples.
>
> Part of the idea with SampleTypes is to make it really easy to plug in a
> streaming audio backend, for instance SampleTypes handles conversion
> between formats, channel counts, and sample rates (currently just linear
> interpolation), so the underlying device libraries don’t have to. SampleBuf
> (the buffer type) is an AbstractArray, and it should be pretty drop-in
> replaceable to normal Arrays, but with extra goodies. If there are cases
> where it doesn’t act like an Array please file an Issue.
>
> LibSndFile.jl  and
> PortAudio.jl  used to be part
> of AudioIO, but are now separate packages. They wrap well-established
> cross-platform C libraries for interacting with files and real-time audio
> devices, respectively.
>
> LibSndFile has been designed to work with FileIO, so loading a file is as
> easy at `load(“myfile.wav”)` and it will figure out the format from the
> extension and magic bytes in the file header.
>
> PortAudio.jl has been massively simplified from what was in AudioIO. Test
> coverage is at 95%, but because PortAudio doesn’t provide a way to simulate
> input the tests aren’t very strong. They also don’t run on Travis.
>
> JACKAudio.jl  is a wrapper
> for libjack, a great audio routing tool designed for low-latency, pro audio
> applications. Unfortunately we’re not yet at the point where we can get
> super low latency from Julia, but it’s working pretty well now and I think
> there’s still room to tune it for better performance.
>
> RingBuffers.jl  is a small
> utility package that provides the RingBuffer type. It’s a fixed-size
> multi-channel circular ringbuffer with configurable overflow/underflow
> behavior. It uses normal Arrays and is not specific to this architecture,
> except that is assumes each channel of data is a column of a 2D Array.
>
> Here’s a screenshot from the PortAudio README that gives a good flavor for
> the sort of things these packages can do together:
>
>
> Please kick the tires and let me know what doesn’t work or is confusing.
> Also, if you maintain an audio-related package and want to plug into this
> architecture, I’d be happy to start growing the JuliaAudio organization
> both in maintainers and packages.
>
> -s
>

Re: [julia-users] [ANN] JuliaAudio Organization and a slew of packages

[Spencer Russell]

If I were feeling verbose I would say it’s a collection of types for managing 
multi-channel data sampled on a 1D uniform grid. Basically it provides stream 
(read/write) and buffer (array-like, random access) types for any 
regularly-sampled data, like EEG, Software-defined radio (complex samples), and 
audio. The samples themselves (in the sense of individual point measurements) 
are just a type parameter T.

I see your point Tony about “Sample” in the sense of “Example”. My brain 
doesn’t like to say “SampledTypes” though. Maybe just “Sampled.jl” (though that 
could be confused with other “samples”, like sampling from a distribution). 
“SampledSignals.jl” maybe?

-s

> On Mar 20, 2016, at 7:35 PM, Stefan Karpinski  wrote:
> 
> I think it's a package of types for defining samples, not a collection of 
> types which are sampled, so I don't think that would be clearer (unless I'm 
> misunderstanding what the package is for).
> 
> On Sun, Mar 20, 2016 at 7:10 AM, Tony Kelman  > wrote:
> Would SampledTypes maybe be a bit clearer? Otherwise it reads a bit like it 
> would contain examples.
> 
> 
> 
> On Sunday, March 20, 2016 at 2:31:28 AM UTC-7, Spencer Russell wrote:
> Hey there, Julians.
> 
> So AudioIO has been languishing for some time now, and I’ve been busily 
> working away at the next generation. One of the issues with AudioIO is that 
> it was a lot to swallow if you just wanted to play or record some audio. I’ve 
> been focusing on getting the fundamental APIs right, so that the fancy stuff 
> can be built on top.
> 
> There’s a new JuliaAudio  organization and 5 
> shiny new packages. They’re still pretty young, but most of them have good 
> test coverage. I’m planning on registering to METADATA soon, but I wanted to 
> solicit some feedback first.
> 
> SampleTypes.jl  is the most 
> important as it defines the architecture that glues together the rest of the 
> packages. It defines a set of stream and buffer types that should make it 
> easy to move sampled data around. It’s called SampleTypes instead of 
> AudioTypes because it should be useful for any sort of regularly-sampled, 
> multi-channel data (e.g. complex samples from an SDR, multi-channel EEG, 
> etc.). The types are sample-rate aware, and the samplerate can be stored in 
> real units using SIUnits.jl. That allows cool features like reading in data 
> using seconds instead of samples. 
> 
> Part of the idea with SampleTypes is to make it really easy to plug in a 
> streaming audio backend, for instance SampleTypes handles conversion between 
> formats, channel counts, and sample rates (currently just linear 
> interpolation), so the underlying device libraries don’t have to. SampleBuf 
> (the buffer type) is an AbstractArray, and it should be pretty drop-in 
> replaceable to normal Arrays, but with extra goodies. If there are cases 
> where it doesn’t act like an Array please file an Issue.
> 
> LibSndFile.jl  and PortAudio.jl 
>  used to be part of AudioIO, but 
> are now separate packages. They wrap well-established cross-platform C 
> libraries for interacting with files and real-time audio devices, 
> respectively.
> 
> LibSndFile has been designed to work with FileIO, so loading a file is as 
> easy at `load(“myfile.wav”)` and it will figure out the format from the 
> extension and magic bytes in the file header.
> 
> PortAudio.jl has been massively simplified from what was in AudioIO. Test 
> coverage is at 95%, but because PortAudio doesn’t provide a way to simulate 
> input the tests aren’t very strong. They also don’t run on Travis.
> 
> JACKAudio.jl  is a wrapper for 
> libjack, a great audio routing tool designed for low-latency, pro audio 
> applications. Unfortunately we’re not yet at the point where we can get super 
> low latency from Julia, but it’s working pretty well now and I think there’s 
> still room to tune it for better performance.
> 
> RingBuffers.jl  is a small 
> utility package that provides the RingBuffer type. It’s a fixed-size 
> multi-channel circular ringbuffer with configurable overflow/underflow 
> behavior. It uses normal Arrays and is not specific to this architecture, 
> except that is assumes each channel of data is a column of a 2D Array.
> 
> Here’s a screenshot from the PortAudio README that gives a good flavor for 
> the sort of things these packages can do together:
> 
> 
> 
> Please kick the tires and let me know what doesn’t work or is confusing. 
> Also, if you maintain an audio-related package and want to plug into this 
> architecture, I’d be happy to start growing the JuliaAudio organization both 
> in maintainers and packages.
> 
> -s
> 

Re: [julia-users] [ANN] JuliaAudio Organization and a slew of packages

[Stefan Karpinski]

SampledSignals seems to convey the meaning pretty well.

On Mon, Mar 21, 2016 at 12:40 PM, Spencer Russell  wrote:

> If I were feeling verbose I would say it’s a collection of types for
> managing multi-channel data sampled on a 1D uniform grid. Basically it
> provides stream (read/write) and buffer (array-like, random access) types
> for any regularly-sampled data, like EEG, Software-defined radio (complex
> samples), and audio. The samples themselves (in the sense of individual
> point measurements) are just a type parameter T.
>
> I see your point Tony about “Sample” in the sense of “Example”. My brain
> doesn’t like to say “SampledTypes” though. Maybe just “Sampled.jl” (though
> that could be confused with other “samples”, like sampling from a
> distribution). “SampledSignals.jl” maybe?
>
> -s
>
>
> On Mar 20, 2016, at 7:35 PM, Stefan Karpinski 
> wrote:
>
> I think it's a package of types for defining samples, not a collection of
> types which are sampled, so I don't think that would be clearer (unless I'm
> misunderstanding what the package is for).
>
> On Sun, Mar 20, 2016 at 7:10 AM, Tony Kelman  wrote:
>
>> Would SampledTypes maybe be a bit clearer? Otherwise it reads a bit like
>> it would contain examples.
>>
>>
>>
>> On Sunday, March 20, 2016 at 2:31:28 AM UTC-7, Spencer Russell wrote:
>>>
>>> Hey there, Julians.
>>>
>>> So AudioIO has been languishing for some time now, and I’ve been busily
>>> working away at the next generation. One of the issues with AudioIO is that
>>> it was a lot to swallow if you just wanted to play or record some audio.
>>> I’ve been focusing on getting the fundamental APIs right, so that the fancy
>>> stuff can be built on top.
>>>
>>> There’s a new JuliaAudio  organization and
>>> 5 shiny new packages. They’re still pretty young, but most of them have
>>> good test coverage. I’m planning on registering to METADATA soon, but I
>>> wanted to solicit some feedback first.
>>>
>>> SampleTypes.jl  is the
>>> most important as it defines the architecture that glues together the rest
>>> of the packages. It defines a set of stream and buffer types that should
>>> make it easy to move sampled data around. It’s called SampleTypes instead
>>> of AudioTypes because it should be useful for any sort of
>>> regularly-sampled, multi-channel data (e.g. complex samples from an SDR,
>>> multi-channel EEG, etc.). The types are sample-rate aware, and the
>>> samplerate can be stored in real units using SIUnits.jl. That allows cool
>>> features like reading in data using seconds instead of samples.
>>>
>>> Part of the idea with SampleTypes is to make it really easy to plug in a
>>> streaming audio backend, for instance SampleTypes handles conversion
>>> between formats, channel counts, and sample rates (currently just linear
>>> interpolation), so the underlying device libraries don’t have to. SampleBuf
>>> (the buffer type) is an AbstractArray, and it should be pretty drop-in
>>> replaceable to normal Arrays, but with extra goodies. If there are cases
>>> where it doesn’t act like an Array please file an Issue.
>>>
>>> LibSndFile.jl  and
>>> PortAudio.jl  used to be
>>> part of AudioIO, but are now separate packages. They wrap well-established
>>> cross-platform C libraries for interacting with files and real-time audio
>>> devices, respectively.
>>>
>>> LibSndFile has been designed to work with FileIO, so loading a file is
>>> as easy at `load(“myfile.wav”)` and it will figure out the format from the
>>> extension and magic bytes in the file header.
>>>
>>> PortAudio.jl has been massively simplified from what was in AudioIO.
>>> Test coverage is at 95%, but because PortAudio doesn’t provide a way to
>>> simulate input the tests aren’t very strong. They also don’t run on Travis.
>>>
>>> JACKAudio.jl  is a wrapper
>>> for libjack, a great audio routing tool designed for low-latency, pro audio
>>> applications. Unfortunately we’re not yet at the point where we can get
>>> super low latency from Julia, but it’s working pretty well now and I think
>>> there’s still room to tune it for better performance.
>>>
>>> RingBuffers.jl  is a
>>> small utility package that provides the RingBuffer type. It’s a fixed-size
>>> multi-channel circular ringbuffer with configurable overflow/underflow
>>> behavior. It uses normal Arrays and is not specific to this architecture,
>>> except that is assumes each channel of data is a column of a 2D Array.
>>>
>>> Here’s a screenshot from the PortAudio README that gives a good flavor
>>> for the sort of things these packages can do together:
>>>
>>>
>>> Please kick the tires and let me know what doesn’t work or is confusing.
>>> Also, if you maintain an audio-related package and want to plug into this
>>> archit