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

[IOhannes m zmölnig]

On 12/27/2012 21:36, 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.


pulse audio never worked for me on various debian gnu/linux setups.
these days i only ever use alsa and jack, and i believe that one of 
these (preferably the latter) should be the default for a pro-grade 
audio software.

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


and i strongly agree with roman, that we should differentiate between 
audio-processing on/off and switching audiobackends on/off.

i think the easiest way would be:
- assume that all backends are blocking
- provide a dummy backend that writes to /dev/null (or whatever the 
equivalent on platform foo)
- make dsp 1/0 turn the audio processing on/off. if dsp is off, any 
active audio backends should be fed with zeros (to prevent 1-block loops)

gmsdrt
IOhannes