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? Roman _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
