Re: GSOC audio priorities

[Rik]

On 07/10/2013 03:00 AM, address@hidden wrote:
>    1. Octave audio project progress and schedule (Mike Miller)
>
> 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?
7/10/13

I would vote up writing the audioread and audiowrite functions.  Without
these it seems like the player functionality could be orphaned.  That is,
Octave could play sounds but have very little means of getting any input to
actually play.  I also think the integration with core should take place on
the early side.  Files are easy to add to Mercurial, but if this is going
to involve outside libraries like libsndfile then configure.ac and the
build system may have to have special tests and these can be tricky to
write.  I would down vote creating the timer class.  It's a good idea, but
nobody has thought of how exactly we want to do this in the core and I
think some planning is necessary first.  I also like the alternative
project of enabling stream processing of sound via a callback function. 
This seems particularly important as collecting one large matrix before
processing may be impossible due to memory constraints on the host.

--Rik
> -- mike