starting audio reliably

Jun 29, 2006 at 9:33am

starting audio reliably

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

#26620
Jun 29, 2006 at 10:01am

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

http://users.skynet.be/crfmw/max

#79876
Jun 29, 2006 at 11:19am

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:

#79877
Jun 29, 2006 at 1:00pm

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

http://users.skynet.be/crfmw/max

#79878
Jun 29, 2006 at 2:04pm

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.

#79879
Jun 29, 2006 at 8:13pm

> 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

#79880

You must be logged in to reply to this topic.