On Don, 2012-12-27 at 16:06 -0500, Hans-Christoph Steiner wrote: > 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.
I'm not sure you understood my proposal. Exactly _because_ it might not make sense for all APIs, I suggested to use a separate message for API on|off, so that 'dsp 0|1' can behave exactly the same with all APIs (as it used to do anyway before 0.43). Does that make sense? Example: I often use an idiom [dsp 0, dynamically create stuff, dsp 1] in my patches. I wouldn't want this to work nicely only with -jack while causing ugly clicks with -alsa or -oss. The patchs behaviour shouldn't be affected by the audio API currently in use. Roman _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
