I'm not asking when you would implement this. We were talking about
determinism, after all. :)
But I guess I'm confusing a program's deterministic behavior-- e.g., outputat
predictable times-- with a message that has a value derived from machine- or
OS-specific behavior.
-Jonathan
On Tuesday, October 6, 2015 3:32 PM, Miller Puckette <[email protected]> wrote:
I don't think the design constrains it out - I just haven't done it, since
it's rather more than a minor project.
cheers
M
On Tue, Oct 06, 2015 at 07:27:51PM +0000, Jonathan Wilkes wrote:
> Hm... still, I can't get that value from within a patch because of your
> design constraints, right?
>
>
> On Tuesday, October 6, 2015 2:20 PM, Miller Puckette <[email protected]>
>wrote:
>
>
> So in that case you'd really want a different metric, perhaps 'what was the
> minimum fill count while the file was playing'.
>
> cheers
> M
>
> On Tue, Oct 06, 2015 at 05:40:27PM +0000, Jonathan Wilkes via Pd-list wrote:
> > But as Matt's student I want to be able to measure the time it takes to
> > open the file, to make a more informed decision when I design my patch. I
> > wantthe pure data when I'm only opening a few soundfiles, and then Iwant
> > the pure data when I try to open lots of files. Pd already gives
> > me[realtime] which I could use to create non-deterministic patches.
> > Obviouslyits author realized that the ability to measure time outweighs the
> > risk of doingthat. One would assume that same tradeoff to be equally
> > important, if notmoreso, for the few instances of object behavior which
> > [realtime] cannotmeasure.
> > The other students are now rolling their eyes. I think they're on to me.
> > -Jonathan
> >
> >
> >
> > On Tuesday, October 6, 2015 12:11 PM, Miller Puckette <[email protected]>
> >wrote:
> >
> >
> > A worthy question.
> >
> > If you want the soundfile to start exactly when you specify it (I think this
> > should normally be the case :) then it's beside the point exactly when the
> > computer could have coughed it up - it only matters that it be there by the
> > desired time.
> >
> > If you want the soundfile to play "whenever the computer can manage it" -
> > and
> > the sooner the better - well, then a "ready" message would be useful. I
> > imagine one could shave off 1/5 second or so, but it would be inconsistent.
> > Perhaps this is useful in some cases but I don't think it would be often -
> > and the downside is that it wouldn't be deterministic (a fundamental design
> > principle of Pd).
> >
> > cheers
> > Miller
> >
> >
> > On Tue, Oct 06, 2015 at 03:58:38PM +0000, Jonathan Wilkes wrote:
> > > If I were one of Matt's students, I'd ask why this "Pure Data readsf~
> > > business" won't just tell me when it has actually opened the file. Why
> > > does thecomputer get to know when it's ready, but we students have to
> > > guess bylistening for glitches?
> > > -Jonathan
> > >
> > >
> > >
> > > On Tuesday, October 6, 2015 1:02 AM, Matt Barber
> > ><[email protected]> wrote:
> > >
> > >
> > >
> > > 4) Has anyone ever “broken” these objects or experienced glitching?
> > >
> > > Once in 2005 we were having awful trouble streaming through Pd but we
> > > were never sure whether it was [readsf~] per se, a very slow disk, or
> > > xruns in ALSA/JACK, and we had only one performance laptop available. My
> > > best guess is that it was an ALSA/JACK problem, since other software had
> > > a few issues with glitching just on realtime audio processing.
> > > pthread_mutex_lock() ... This might be a good time for a PSA for
> > > interested newcomers to Pd, though, if any happen to be following this
> > > thread (ahem). Having taught Pd for some 10 years now, one bad habit I've
> > > seen nearly every student fall into is failing to preload the file before
> > > playing, trying to do the initial read and the playing at the same
> > > logical time. Usually there isn't a problem, but once in a while a taxed
> > > system that is already streaming several files can glitch hard on a new
> > > stream. I've attached a generic [readsf~] idiom that has been useful for
> > > first-year students when they want to jump in and get Pd to play some
> > > sound files with a GUI after they've fooled around with the control
> > > examples and oscillators. This is before we get into event triggering, so
> > > the clunky multiple play/stop buttons is edited out later on; the main
> > > thing is how to keep the file open at all times. This turns out to be
> > > even more important for rehearsal than for performance, when you need to
> > > be able to jump around at will. ... pthread_mutex_unlock()
> > >
> > >
> > > On Tue, Oct 6, 2015 at 12:15 AM, Miller Puckette <[email protected]> wrote:
> > >
> > > I think you can get away with sharing a lock between two high-prioroty
> > > processes as long as neither one holds the lock for more than a small
> > > amount of time and if the OS can be counted on to give control to a
> > > real-time
> > > process quickly once it becomes runnable (i.e., if it's blocked on a lock,
> > > once that lock is released).
> > >
> > > The situation I don't know about is this: if Pd's main thread failed to
> > > get
> > > the lock, so that control (presumably) passed back to the other thread
> > > that
> > > had the lock, how much time can pass before the other thread blocks on
> > > something so that control (again presumably) gets passed back to the main
> > > thread?
> > >
> > > But anyway, since neither thread holds onto the lock for more than a few
> > > lines of C code (with no system calls) it's probably blue-moon rare that
> > > the
> > > scheduler interrupts one thread right in the middle of a critical section
> > > and
> > > passes control to the other one that then blocks. So this is essentially
> > > untested.
> > >
> > > Threads can never be used confidently in a real-time situation. But I
> > > don't
> > > see any reasonable way without them to implement readsf~/writesf~, so
> > > there
> > > we are...
> > >
> > > cheers
> > > Miller
> > >
> > > P.S. one can issue non-blocking reads/writes, but there's also "open"
> > > which
> > > is much more likely to hiccup than "read", and I don't know of any async
> > > open
> > > call in any OS.
> > >
> > >
> > > On Tue, Oct 06, 2015 at 03:10:31AM +0000, Jonathan Wilkes via Pd-list
> > > wrote:
> > > > 1) One thing I noticed is that the article you cited seems to focus
> > > > on tasks not critical to the computation/delivery of audio samples.For
> > > > example, if your program were blocking or locking in order to do a
> > > > GUIupdate. But here, the data must arrive in time to compute the next
> > > > block. If ittakes too long to read the next portion of the sound file,
> > > > then you're going to geta glitch.
> > > > But I'm not sure I really grasp how locking works, nor really the whole
> > > > file i/oprocess in general.
> > > >
> > > > Here's a naive question: why can't you just tell the OS to treat the
> > > > file asif it were a non-blocking socket, add the fd to Pd's event loop
> > > > with
> > > > sys_addpollfn, and then receive the incoming data to the relevant
> > > > function?(Warning: some or all of the above may technically be
> > > > gibberish...)
> > > >
> > > > -Jonathan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Monday, October 5, 2015 10:01 PM, Robert Esler
> > > ><[email protected]> wrote:
> > > >
> > > >
> > > > I’m trying to understand why readsf~ and writesf~ work so well.
> > > >
> > > > I’m particularly referencing Ross Bencina’s article:
> > > > http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing
> > > > and his subsequent paper,
> > > > http://www.rossbencina.com/static/writings/File_IO_ACMC2014_Bencina.pdf
> > > >
> > > > If you are not into asynchronous message passing and lock-free queueing
> > > > then I’ll summarize the articles briefly:
> > > >
> > > > When engaging in file I/O (e.g reading from or writing to an audio
> > > > file) do not use locks or blocking. He goes on to say that this can
> > > > lead to priority inversion, unbound execution time and “scheduler
> > > > paranoia”.
> > > >
> > > > This is all absolutely true in my experience in the audio jungle.
> > > >
> > > > Pd’s async file I/O objects (readsf~ and writesf~) use both locks and
> > > > blocking via a mutex and the pthread_cond_signal and pthread_cond_init
> > > > functions. Look at the source code file d_soundfile.c for more
> > > > details. The gist of it is that these objects have two threads. One
> > > > parent thread that sends the data to the dsp scheduler, and a child
> > > > thread that grabs the data from the file, and subsequently the child
> > > > signals the parent when it has more data.
> > > >
> > > > Based on Bencina’s paper, readsf~ and writesf~ could (should?) glitch
> > > > and may not be real-time safe.
> > > >
> > > > My questions are:
> > > >
> > > > 1) Have I completely misunderstood d_soundfile.c and it is actually
> > > > entirely safe. If so, why is it safe?
> > > >
> > > > 2) Why doesn’t Pd glitch more often when using these objects?
> > > >
> > > > 3) Does Pd need lock-free message queueing for such inter-thread
> > > > communication?
> > > >
> > > > 4) Has anyone ever “broken” these objects or experienced glitching?
> > > >
> > > > Thanks for the extra brain power.
> > > > -R
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > [email protected] mailing list
> > > > UNSUBSCRIBE and account-management ->
> > > > http://lists.puredata.info/listinfo/pd-list
> > > >
> > > >
> > > >
> > >
> > > > _______________________________________________
> > > > [email protected] mailing list
> > > > UNSUBSCRIBE and account-management ->
> > > > http://lists.puredata.info/listinfo/pd-list
> > >
> > >
> > > _______________________________________________
> > > [email protected] mailing list
> > > UNSUBSCRIBE and account-management ->
> > > http://lists.puredata.info/listinfo/pd-list
> > >
> > >
> > >
> > >
> > >
> >
> >
>
> > _______________________________________________
> > [email protected] mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
>
>
>
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
