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