starting audio reliably


    Jun 29 2006 | 9:33 am
    I have a medium-sized MSP patch with a couple of subpatchers running
    in an installation. I have a loadbang object connected to some
    messages to initialize stuff. One of these messages (the last)
    triggers the 'start' message connected to an adc~ object.
    This fails if I don't delay the 'start' message for some time, say
    100 mS. Unfortunately, even after adding the delay object, the audio
    fails to start once in a while. This means no audio until the
    installation is automatically reset the next day.
    My question: is there a more reliable/failsafe method to start DSP?
    Best,
    Zip Boterbloem
    Media Mechanics
    Zwaluwstraat 54
    2025 VR Haarlem
    The Netherlands
    +31627014758
    zip@knoware.nl

    • Jun 29 2006 | 10:01 am
      100ms may be too short. If it's for an installation, then you have
      probably time to wait much longer.
      If the computer booted just before the patch is opened, then you should
      also delay the startup of MAx. For an installation I did, I noticed
      that the soundcard (a m-audio410) was never available when the patch
      was automatically opened at startup. On OSX, I did a small script in
      Automator to delay the launch of my MAxMSP stadalone.
      _____________________________
      Patrick Delges
      Centre de Recherches et de Formation Musicales de Wallonie asbl
    • Jun 29 2006 | 11:19 am
      Hi Patrick,
      Thanks for your reply.
      I already use a UNIX script to delay the launch of max for a minute,
      so the MOTU Traveler has time to settle.
      I don't mind increasing the delay value for the 'start' message, but
      this still feels like a hit and miss solution. In my experience,
      these sort of 'solutions' invariably fail in an installation at some
      point.
      Best,
      Zip Boterbloem
      Media Mechanics
      Zwaluwstraat 54
      2025 VR Haarlem
      The Netherlands
      +31627014758
      zip@knoware.nl
      Op 29-jun-2006, om 12:01 heeft Patrick Delges het volgende geschreven:
    • Jun 29 2006 | 1:00 pm
      I never liked [delay] in my patches neither... But in such a case,
      where external harware and driver are involved, I don't think it's such
      a bad solution.
      Maybe you can try to send to [adstatus driver] the name of the driver
      you want until it is indeed set and then turn on the [dac~].
      It may be considered as bad practice, but I don't turn off the computer
      when the installation isn't running (I just fade out the sound
      outputs). So the computer (a MacMini) is running since almost 1 year
      (no disk access in my patch, everything is in RAM). But I know it
      restarted a couple of times, because of some storms... It worked so
      far!
      p
      _____________________________
      Patrick Delges
      Centre de Recherches et de Formation Musicales de Wallonie asbl
    • Jun 29 2006 | 2:04 pm
      why not just keep sending a 1 to the dac~ every second. With my soundcard it doesn't do anything [like restart] to the audio if its already processing.
    • Jun 29 2006 | 8:13 pm
      > It may be considered as bad practice, but I don't turn off the
      > computer when the installation isn't running (I just fade out the
      > sound outputs). So the computer (a MacMini) is running since almost
      > 1 year (no disk access in my patch, everything is in RAM). But I
      > know it restarted a couple of times, because of some storms... It
      > worked so far!
      Unfortunately the museum switches off all computers & other machines
      in the exhibition rooms after closing. I was told they have to
      because of their insurance(risk of fire).
      Anyway, I'll increase the 'start' delay to two seconds and let's hope
      that helps.
      BTW, I find it hard to make bullet-proof Max patches. Stuff will work
      fine for days, and then suddenly something goes wrong. Most of the
      times Max will not crash, but sound/DSP will stop for some reason.
      Very difficult to decipher a pattern, it's not necessary a CPU
      overload, could be anything. This is on vanilla G5's and mini's
      running Tiger. DSP load is never more than 40% on any one machine.
      I've been toying with the idea of having some sort of feedback system
      that restarts the system if the max thread suddenly changes CPU
      consumption, eg suddenly jumps to 80% or 10% and stays there for more
      than say 1 minute. But that's tricky, and the Unix stuff (daemons?)
      is a bit above my head.
      Has anyone ever tried such a system? Or has more detailed ideas how
      to implement it?
      Best,
      Zip