[PD] [PD-announce] pd 0.44-0 test 1 released

[Roman Haefeli]

On Don, 2012-12-27 at 15:29 -0500, Hans-Christoph Steiner wrote:
> On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
> 
> > On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
> >> Hi all -
> >> I'm afraid to 'fix' this riht now, but will look at it at least.  Alternatively
> >> I could add a message to pd to restort DSP without stopping/starting the
> >> audio I/O, which I'm hoping will at least reduce the need to start/stop
> >> SDP all the time.
> >> 
> >> The change that caused this problem is that I fixed Pd not to have the audio
> >> system open whern DSP isn't running so that, on APIs in which audio is exclusive
> >> (e.g., ALSA) you can turn DSP off in Pd and go off and use another device
> >> with Pd remining open.
> > 
> > The problem arises when there is one message trying to control many
> > different tasks:
> > * switch DSP computing on/off (save CPU time)
> > * free/occupy the audio back-end (save soundcard time)
> > * mute/unmute Pd (save ears)
> > * force recompilation of the DSP graph
> > 
> >> An alternative would be to have Pd automatically close audio devices on ALSA,
> >> OSS, and MMIO but always keep it open when using jack.  But then what about
> >> portaudio?  I somply don't know the correct way to deal with this.
> > 
> > I'd say it's preferable if Pd's behavior is independent from the
> > back-end currently in use. Rather, I suggest to use different messages
> > for different tasks. IMHO, 'dsp 0' really should only turn computation
> > of tilde-objects off as this is what it means and what one expects. What
> > about a new message to pd 'card 0|1' to free devices which would work
> > completely independently from 'dsp 0|1'? This would allow to record a
> > signal to a soundfile without occupying the soundcard, for instance.
> 
> I think that having a pulseaudio backend for Pd as the default on
> GNU/Linux would be the best way to solve this problem.  Pulse will
> then handle the multiple apps playing at the same time.  Then for
> people who want to skip Pulse, then can use the ALSA blocking
> implementation.
> 
> An Audio API can be quite different than another, so I don't think it
> makes sense to treat them all the same in terms of things like whether
> DSP disconnects the audio API.  For example Mac OS X CoreAudio, even
> through PortAudio, always has handled multiple apps playing back.  And
> the "audio stuck" workaround actually only causes problems with
> CoreAudio.

So you agree that 'dsp 0|1' should not automatically disconnect|connect
the audio API, regardless of what API is in use?

Roman