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. .hc > > Roman > > >> And merry Christmas too... >> >> On Mon, Dec 24, 2012 at 10:09:37PM +0100, IOhannes m zmölnig wrote: >>> On 12/22/2012 02:48, Miller Puckette wrote: >>>> Hi all, >>>> >>>> Pd version 0.44-0test1 is available on >>>> http://crca.ucsd.edu/~msp/software.htm >>>> or via git from sourceforge: >>>> git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data >>>> >>> >>> >>> cool, but... >>> >>>> mostly audio, MIDI, scheduling, and OS compatibility bug fixes. >>> >>> ...i'm unsure what to think about the current jack situation. >>> as it is (at least is in my cop of pd-0.44), taken from todays git), >>> if i turn on/off audio, the Pd-jack client appears/disappears. >>> roman reported this as a bug and i thought this was going to be >>> fixed for 0.44, but it seems that it is still there. >>> what are the plans for this? >>> >>> >>> fgamsdr >>> IOhannes >>> >>> >>> PS: merry christmas! >>> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
