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

[Roman Haefeli]

On Don, 2012-12-27 at 16:06 -0500, Hans-Christoph Steiner wrote:
> On Dec 27, 2012, at 3:36 PM, Roman Haefeli wrote:
> 
> > 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?
> 
> I don't know enough about the various audio APIs to say whether that's
> a good idea or not.  Perhaps it makes sense with some audio APIs.

I'm not sure you understood my proposal. Exactly _because_ it might not
make sense for all APIs, I suggested to use a separate message for API
on|off, so that 'dsp 0|1' can behave exactly the same with all APIs (as
it used to do anyway before 0.43). Does that make sense?

Example:
I often use an idiom [dsp 0, dynamically create stuff, dsp 1] in my
patches. I wouldn't want this to work nicely only with -jack while
causing ugly clicks with -alsa or -oss. The patchs behaviour shouldn't
be affected by the audio API currently in use.
 
Roman