Hey Matt,I don't have access to an instance of Pd atm, but I'll try it out when
I do.
Yes, an improvisation is what I had in mind. I imagine someone throwing
virtual playing cards onto a table, and each card turnsgreen when it's ready to
be clicked to produce audio.
What happens if I throw all 55 cards on the table?[1]
-Jonathan
[1] standard deck plus two jokers and an instruction card
On Wednesday, October 7, 2015 4:12 AM, Matt Barber <[email protected]>
wrote:
I think Ableton allows you to choose whether you want to stream from disk or
load to RAM.
Keeping data in RAM depends on what you're trying to play. If you need to
playback something like an hour-long 8-channel file @ 96k, pretty much your
only practical option is disk streaming (but you might be looking at a
dedicated playback software rather than [readsf~] in that case).
On Wed, Oct 7, 2015 at 2:59 AM, Robert Esler <[email protected]> wrote:
Matt,I think on a Desktop OS keeping the data in RAM wouldn’t be much of an
issue. I’m sure software like Ableton’s Live doesn’t stream audio from disk.
But on something where RAM is scarce like a mobile phone or single board CPU
the OS may not provide enough memory and fail. Especially with libpd becoming
more ubiquitous, a real-time safe streaming option may be valuable.
But you’re right, the designer has a choice as to how data is accessed and
should know the potential consequences. Education is still key.
-Rob
On Oct 6, 2015, at 11:15 PM, Matt Barber <[email protected]> wrote:
Out of curiosity, can you give a test case where my idiom above (which keeps
the file loaded as long as you need it) would be too onerous or just impossible
to use? I think I can think of a few, like some kind of patch that follows an
improvisation and chooses files to stream immediately in response to something
the performer did. In those cases, though, I'd be very reluctant to trust the
disk drive to serve multiple files immediately. SSDs might perform better and a
ramdisk better still, but in the general case I think I would do everything I
could do design my composition/patch to be consistent with preloading any files
I need immediately.
On Tue, Oct 6, 2015 at 4:41 PM, Jonathan Wilkes via Pd-list
<[email protected]> wrote:
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
