octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Octave audio project progress and schedule


From: Mike Miller
Subject: Octave audio project progress and schedule
Date: Tue, 9 Jul 2013 17:55:20 -0400

Sorry I took all day to get back to you. I'm cc'ing the maintainers
list at this point so our discussion is public, and so everyone can be
informed on the project progress and provide input if they want.

@maintainers, we're talking about the schedule of the audio I/O GSoC project.

I wrote:
>> Lastly, according to the schedule you proposed for this project, you
>> are a bit ahead on the audioplayer and audiorecorder functionality. Do
>> you want to revise the schedule or make any changes at this point?
>> Since you are ahead, now might be a good time to assess where we are
>> and decide if we want to keep the same goals, add more, or shuffle
>> things around. What do you think? The wiki and your blog would both be
>> good places to keep an up-to-date schedule.

Vytautas Jancauskas wrote:
> I was thinking maybe I should do both audioplayer and audiorecorder
> before the midterm. It is very difficult to pin point when exactly
> will they be "done" since issues may crop up if people try actually
> using them.

That sounds good to me. So from now until 2013-07-29 you could spend
finishing the majority of the functionality of the audiorecorder and
audioplayer classes. Given the rate of your progress so far, I'd say
that's a very reasonable goal. Yes, we could definitely use some
testing from other people with different/multiple sound cards and
different operating systems.

> After the midterm I was thinking maybe I could do
> http://www.mathworks.se/help/matlab/reading-and-writing-files.html the
> first 3 of these? using maybe libsndfile
> http://www.mega-nerd.com/libsndfile/. The ones that are currently in
> octave don't seem very complete.

I'd say hold off on that until later in the project. Yes, that does
sound like a good thing to work on, and libsndfile does sound like a
good candidate, but there are probably other priorities.

> Maybe the timer class too just for
> the completeness?

Maybe. Maybe others can weigh in or have ideas for how to get that
aspect working. For others reading along, the audio classes allow you
to register optional callback functions for the start and end of a
playback or recording, as well as periodically. These are similar to
callbacks provided by the timer class, which is also currently a
missing piece of Octave. We could implement this in the audio classes
directly, or wait until we have a proper timer implementation for
Octave. (This would be a good thing to write about on your project
blog, by the way.)

> Do you have some suggestions?

I ask the same of the maintainers list, does anyone have suggestions
or preferences for the most important audio I/O capabilities to fit in
this project?

Here's an abbreviated version of the original proposed schedule for reference:

June: Finish implementing audiodevinfo
July: Implement audioplayer class
August: Implement audiorecorder class
September: Polish existing code, write unit tests, documentation,
implement legacy functions
Leftover time: I would like to experiment with callback based audio playback

Keeping an updated, evolving schedule alongside your weekly progress
is a good thing to post on your blog regularly, so anyone can see at a
glance where you are in the project timeline.

After midterm you have 6-7 weeks. Assuming most of audiorecorder is
done by end of July, I doubt the remaining tasks will take that long.
So, my suggestions:

I like your idea of adding a callback function to provide playback
data instead of a matrix. You could definitely also extend this to
recording, so I could have a callback function that would process
incoming audio as a stream instead of having to store the entire
matrix in memory.

I like the idea of merging octave-sound into Octave. Since all of this
code will eventually go into Octave core, you might want to consider
doing this sooner rather than later. If it's not done as part of this
project term, it should be done as soon after as possible. What do you
think?

And of course don't underestimate the importance and time required to
write tests and documentation, although keep in mind your unit tests
will have to test the functionality of the classes without a guarantee
of a sound card even existing.

The timer callback functions and audio file-based I/O functions are
separate enough from the main focus of this project that I'd say only
look at them after these other tasks are complete.

This is my take on the project, any others?

-- 
mike


reply via email to

[Prev in Thread] Current Thread [Next in Thread]