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

[Hans-Christoph Steiner]

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.

.hc