octave-maintainers
[Top][All Lists]
Advanced

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

GSoC audio callbacks


From: Mike Miller
Subject: GSoC audio callbacks
Date: Tue, 13 Aug 2013 13:56:02 -0400

Hi Vytautas,

I took a look at the latest audio feature you added, callback
functions for playback and recording [1]. For everyone else following
along, this is an Octave extension that will allow a user function to
supply or consume an audio stream in real-time rather than storing the
entire signal in memory.

[1] 
http://gsoc2013octaveaudio.blogspot.com/2013/08/writing-portaudio-callbacks-in-octave.html

I had better luck with the playback, and it definitely worked better
for me than when I tried it the week before. There were still some
issues with playback, though, and I didn't get much success from
recording.

Playing audio with a callback:

I created a white noise function and got playback working relatively easily:

  function [y, status] = generate_sound (n)
    y = randn (n, 1);
    status = 1;
  endfunction
  player = audioplayer (@generate_sound);
  play (player);

This did run for quite some time with no problem. I couldn't find
where the status return value was used, so I didn't try different
values there. Eventually (tens of seconds, maybe a minute or two), the
sound changed from white noise to a buzz and I got an error about some
value not being defined. When I tried to stop and play the player
object again, Octave crashed. I will try to reproduce this and get
some more debug information.

Recording audio to a callback:

I tried to do the same with recording, but for some reason the
callback function was only called after I called the stop method. I
did something simple like this:

  function do_record (left, right, n)
    disp (n);
  endfunction
  recorder = audiorecorder (@do_record);
  record (recorder);
  stop (recorder);

The number "512" was displayed once, and only after calling stop.

Do you have a performance reason or use case in mind for separating
the left and right channels the way it is now? Unless there is a
compelling reason, I would think it better to be consistent with the
way audio data is treated now, a single matrix with one column per
channel for multi-channel audio.

To me it makes more sense if the play callback were simply "data =
func (nsamples)" and the record callback is "func (data)", since the
size argument can be inferred from the dimensions of the data matrix.

Let me know if I'm looking at these callbacks wrong or if you want me
to try a different way.

As always, great progress on this project.

-- 
mike


reply via email to

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