Re: gsoc2013 octave audio system

[Vytautas Jancauskas]

On Wed, Apr 17, 2013 at 10:45 PM, Vytautas Jancauskas <address@hidden> wrote:
> On Wed, Apr 17, 2013 at 10:40 PM, Jordi Gutiérrez Hermoso
> <address@hidden> wrote:
>> On 17 April 2013 15:24, Vytautas Jancauskas <address@hidden> wrote:
>>> The repository is here https://bitbucket.org/bucket_brigade/octave-sound
>>
>> Ideally, you should fix the existing playaudio functions under
>> scripts/audio in Octave and you should work with our own source code.
>> Your commitment to long-term involvement Octave will be more evident
>> if you read our source code, use our build tools, and contribute back
>> to our existing codebase. I was envisioning this project as fixing the
>> existing playaudio functions in core Octave. Have you at least read
>> those functions and realised why they are so poorly implemented?
>
> That is not the consensus I am getting here. The idea is to
> re-implement matlab classes audioplayer and audiorecorder. Yes I have
> read them.
>
>>
>>> I added basic playback using portaudios blocking mode. It will only
>>> work if you have pulseaudio on your system since it looks for "pulse"
>>> device.
>>
>> What's the point of using portaudio and then tying it to pulse? I was
>> hoping that using portaudio wouldn't even make you consider doing
>> something like this. Perhaps portaudio isn't the best choice, if you
>> still have to do things like this.
>
> I don't have to do things like this. This is just a quick demo that
> will work on most modern linux systems without problems, hence this
> choice.
>
>>
>>> You need portaudio19 headers at least. This is just something
>>> to get my feet a little wet. Compile by running scons.
>>
>> Scons? Why? We use autotools here. If you need help figuing out a
>> basic autoconf file, you can look at other OF packages and their
>> configure.ac files.
>>
>
> autotools are garbage with all due respect. But I am open to using
> them if I must.
>
>> - Jordi G. H.

It was also said earlier in this thread that this could be implemented
as a stand-alone package which could later be merged in to the octave
code base. Which is perfectly sensible given that it is not dependent
on any internal Octave stuff.