[PD-dev] what is "audio I/O stuck... closing audio" for?

Lee Azzarello lee at rockingtiger.com
Tue Apr 27 04:49:50 CEST 2010


I have also seen this prior to a performance on OS X. The solution was
to quit PD and restart the patch. It made the sound check a little
more stressful so I'm in support of removing it if it's a false
positive for the audio actually being stuck on that platform.

-lee

On Sun, Apr 25, 2010 at 4:26 PM, Miller Puckette
<mpuckett at imusic1.ucsd.edu> wrote:
> Well, on some systems, the audio device sometimes hangs, and this stops Pd
> dead -- you have to kill it and start over.  I haven't seen it happen on a
> Mac.  So it might be a good idea to #ifdef it away for Mac but keep it in
> for windows.
>
> cheers
> Miller
>
> On Sun, Apr 25, 2010 at 06:52:40PM -0400, Hans-Christoph Steiner wrote:
>>
>> So there is some code in m_sched.c which closes the audio device.  On
>> Mac OS X, it gets triggered when the computer goes to sleep, and then
>> Pd can't play audio any more unless you cycle the DSP or restart Pd.
>> This is an source of confusion for newbies and annoyance for users.  I
>> don't quite understand why there is this code to close the audio
>> device?  Can I just #ifdef it out for Mac OS X?
>>
>>
>>                         /* on 32nd idle, start a clock watch;  every
>>                         32 ensuing idles, check it */
>>                     if (idlecount == 32)
>>                         idletime = sys_getrealtime();
>>                     else if (sys_getrealtime() - idletime > 1.)
>>                     {
>>                         post("audio I/O stuck... closing audio\n");
>>                         sys_close_audio();
>>                         sched_set_using_audio(SCHED_AUDIO_NONE);
>>                         goto waitfortick;
>>                     }
>>
>> It also seems to get triggered a lot on Windows, but I don't know
>> why.  Perhaps this isn't really needed?
>>
>> .hc
>>
>>
>>
>> ----------------------------------------------------------------------------
>>
>> Programs should be written for people to read, and only incidentally
>> for machines to execute.
>>  - from Structure and Interpretation of Computer Programs
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>




More information about the Pd-dev mailing list