----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: IOhannes m zmölnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Thursday, December 27, 2012 7:44 PM Subject: Re: [PD] [PD-announce] pd 0.44-0 test 1 released
On Dec 27, 2012, at 5:23 PM, IOhannes m zmölnig wrote:
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.
Yes, jack is great, and we should make it easy to use. Debian, Ubuntu, Mint, Fedora and others all come with pulseaudio installed and setup by default. That covers probably 75% or more of GNU/Linux users. Pd should have working audio without the users having to do anything at all. So it looks like the only way to achieve that is pulseaudio support. And no, I don't consider Pd's ALSA/OSS connecting to pulseaudio and blocking all other sound a working situation.
I'd like to get a timestamp from IOhannes for his comment on PulseAudio not working on any GNU/Linux systems. When I look at the PulseAudio docs I like what I see, but unfortunately like Gnome 3 the lead developers of PA seemed to have pushed very hard to get a half-baked initial implementation in as many distros as possible so as to cause the maximum amount of flamewars for something that should have otherwise been a solution to many of the usability problems that have plagued GNU/Linux for so long.
In other words if there are _still_ substantial problems with getting PA to behave, maybe we could do an Ardour-style "it just works" default to the jack server that doesn't require the user to have to know they are even using jack. After all, isn't jack cross-platform (and PulseAudio not)?
-Jonathan