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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
