On Sun, Dec 7, 2008 at 5:31 AM, Søren Hauberg <[EMAIL PROTECTED]> wrote: > lør, 06 12 2008 kl. 15:39 -0500, skrev Roman Stanchak: >> I had a minor issue with the existing sound.m in the octave-forge > I do have a few questions: > 1) What platform did you do this on? Linux?
Sorry, yes, Linux. > 2) Can this change potentially introduce an audible "gab" (i.e. a > short period of time where no sound is played) between the blocks? Good point. The audio player has an input buffer (for sox, it's 8192 bytes by default), so presumably if the clip+write operation in octave takes longer than playing 8192 bytes of audio, then a buffer underrun occurs. Informal tests under normal system usage didn't produce any buffer underruns on my Pentium M 1.5ghz laptop. Doing a disk+cpu intensive task while playing audio did result in sporadic buffer underruns. However, this also occurred with the original sound.m, though to a somewhat lesser extent. On an old P3 600mhz, the buffer occassionally underran with the block-writing sound.m, but was otherwise usable. The original sound.m caused the system to swap on the 5minute clip and was therefore completely unusable. IMHO, since Octave is arguably used primarily as an interactive prototyping tool, it is more valuable to have responsive audio playback than gapless playback. Users that absolutely need gapless playback could override the sound_play_utility variable to increase the audio player buffer size or redirect to a file first. --Roman ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
